Repository navigation
Preserve event context and clear inherited account scoping - #2329
jar-stripe wants to merge 5 commits into
Conversation
…bject Event.fetchRelatedObject() used the response getter it was deserialized with directly, so a later no-options mutation on the returned object could pick up whatever default account/context the original client had, instead of the event's own context. EventNotification already avoided this by deserializing with a context-scoped client; give Event the same treatment by adding withStripeContext() to StripeResponseGetter / LiveStripeResponseGetter, and have StripeClient.withStripeContext() delegate to it instead of duplicating the options-cloning logic. Fixes RUN_DEVSDK-3694 (java). Committed-By-Agent: claude
Removed redundant comments about the context scoping.
| default StripeResponseGetter withStripeContext(String context) { | ||
| throw new IllegalStateException( | ||
| "Cannot create a response getter with a custom context for this StripeResponseGetter implementation"); | ||
| } |
There was a problem hiding this comment.
Could this throw errors for our users if they created a client with a custom getter, eg. maybe in tests or something?
There was a problem hiding this comment.
yea thats a good catch. let me play around with this to see how we can do this in a non breaking way.
There was a problem hiding this comment.
Reworked in a455d22. Now, we support a StripeResponseGetter wrapper that injects context and clears account in the default request options and then delegate to the underlying wrapper for all other operations. This should allow custom getters to work with this without an interface change.
zacchua-stripe
left a comment
zacchua-stripe
left a comment
There was a problem hiding this comment.
LGTM! Just had a question about the error thrown by default in StripeResponseGetter
Committed-By-Agent: codex Co-authored-by: codex <noreply@openai.com>
jar-stripe
changed the title
Why?
Event and notification requests must use the context Stripe returned in the payload. Previously, a notification's initial fetch could inherit the original client's
Stripe-Accountwhile also sending the notification'sStripe-Context, a combination the API rejects with HTTP 400. A related object fetched through a fullEventalso retained the original getter, so later mutations could revert to the client's account/context defaults.Fetching and subsequent object operations now share the event's scope. When a notification has no context, its initial fetch clears the inherited context and account, matching the scope already attached to returned objects on master.
What?
StripeResponseGetterinterface unchanged.Validation
just test: all 2,107 tests passed.just format-checkandgit diff --checkpassed.StripeClientTest.eventFetchedRelatedObjectRetainsContextagainst master (afefabe430b): it fails because the initial GET includesStripe-Account. It passes with this change.See Also
Configuration
skip-changefile: This PR is not a user-facing change, so there's no changefile.