async-stripe is multiple API versions behind
Describe the bug
We're looking to use Stripe's Meter APIs which were introduced in 2024, but are unavailable in this crate.
The most recent Stripe API version in this crate appears to be V2023_10_16.
Stripe itself, however, is many API versions ahead of this:
Although the weekly workflows to update async-stripe in accordance with the most recent openapi/spec3.sdk.json are running, the PRs seem to be getting closed on a regular basis, c.f. https://github.com/arlyon/async-stripe/pull/688
I'm digging into the code right now and have already forked the repo into our own org so that we can pick it up, but it sounds like this would be useful to upstream back to this crate. Presumably there's some issue causing async-stripe to get stuck so far behind, but I don't see anything in the PRs which indicates that.
To Reproduce
n/a
Expected behavior
n/a
Code snippets
OS
n/a
Rust version
n/a
Library version
n/a
API version
n/a
Additional context
No response
Our fork is here: https://github.com/BoundaryML/async-stripe/tree/sam/2025-03-31-basil
Note that it has a fair number of hacks to work around the codegen failures.
Does that explain why we're getting random error parsing event object errors for some specific events ? @sxlijin
There's a good chance that it's related, yes: a lot of events have new variants that have been added over the past 2 years, or you may just be receiving new event types.
You'd have to look more closely at which events implode, and probably add a middleware layer to enable yourselves to introspect the events where that happens.
There's a good chance that it's related, yes: a lot of events have new variants that have been added over the past 2 years, or you may just be receiving new event types.
You'd have to look more closely at which events implode, and probably add a middleware layer to enable yourselves to introspect the events where that happens.
Well when I trigger a session checkout completed event locally my Event extractor fails for a bunch of events so I have the list, how would we fix that now ?
You'd have to look at the source code and compare against the Stripe OpenAPI definitions to understand why; I can't really help you with that. You can take a look at the commit history in our fork to see the changes I had to make, which were a combination of (1) re-running the generator and (2) manually fixing compilation errors.
Thanks for noting this @sxlijin! Just also noting the next branch could be interesting to look into for you - it should be more up to date (and more correct in general) and could use support on finalizing API design and any other improvements before a stable release is made. It compiles up to the latest API spec (#708), though a new release will need to be made at some point.
Is there an issue or PR that tracks the readiness of the next branch to be promoted to a crates.io release?
I think https://github.com/arlyon/async-stripe/discussions/77 has the latest discussion, there is also a PR tracking the next branch here (https://github.com/arlyon/async-stripe/pull/526). I think the main pieces are
- Some legwork needs to be done modifying the release process to handle a workspace of crates, and figure out versioning as mentioned in that discussion.
- Making sure crate names make sense
Next is merged and includes support for up to V2025_08_27_basil. I am closing this issue now. Please try it out!