search

stripe / openapi

An OpenAPI specification for the Stripe API.
MIT License
394 stars 123 forks source link

Request: Split `period` into two types #71

Closed phayes closed 1 year ago

phayes commented 3 years ago

It would be nice if period was split up into two types, one might be called period and the the other closed_period.

This would allow us to differentiate between :

  1. periods where start and end might be null and therefore possibly open-ended. This one maps to the current period type.
  2. periods that always have a start and end date (not nullable), we could call this one closed_period. Many instances of the existing period type could be moved into this type.

Right now, null-checking on periods is super annoying, even when I can reasonable assume those values will not be null. However, making assumptions is a bad idea, so this should be represented by concrete types that explicitly delineate when the period is definitely closed, and the start and end non-null.

pakrym-stripe commented 1 year ago

Hi. I'm sorry for the extremely delayed response. Which period do you mean?

If it's the "#/components/schemas/period" it's only used in one place so splitting it won't help. There are some other period fields in the spec but they seem to be appropriately typed to be non-nullable.

pakrym-stripe commented 1 year ago

Closing as inactive, feel free to reopen.

phayes commented 1 year ago

Hi @pakrym-stripe ,

My apologies for not responding. The problem is here: https://stripe.com/docs/api/usage_records/subscription_item_summary_list

The period field in UsageRecordSummary can have a null end-date or null start-date.

pakrym-stripe commented 1 year ago

Sorry, I think I'm missing something. Are you saying that UsageRecordSummary shouldn't have nullable period start and end?

phayes commented 1 year ago

Hi @pakrym-stripe ,

Digging into this further, it looks like the issue has been fixed since I opened this last year. Closing!