Conversation
| String clientId, | ||
| String idempotencyKey, | ||
| String stripeContext, | ||
| String stripeRequestTrigger, |
There was a problem hiding this comment.
it's flagging this (correctly, I think) as a breaking change because the signature has changed.
Is there a better way to roll this out or do we just wait for the major?
There was a problem hiding this comment.
The good news is the next major is EOM. The bad news is this was poorly designed so there is no way to avoid it being breaking. Java objects with builders should always have a private constructor for exactly this reason (and because the ergonomics of multiple input String's in a row is 🤢 ). While you're making a breaking change anyway, I'd go ahead and recommend making this constructor private.
There was a problem hiding this comment.
Good news! RawRequestOptions supports supplying additionalHeaders. So we'll be able to make this change non-breakingly and then i'll leave a TODO + ticket to fix the public constructor for the major.
There was a problem hiding this comment.
spoke too soon 🙈 RequestOptions' constructor is protected, so it has the same problem. We'll just hold this header out of java for now and add it in a week or two.
There was a problem hiding this comment.
Yeesh, yeah protected is no good. We should update that to private too 😅
xavdid-stripe
requested review from
mbroshi-stripe and
prathmesh-stripe
and removed request for
a team and
prathmesh-stripe
| String clientId, | ||
| String idempotencyKey, | ||
| String stripeContext, | ||
| String stripeRequestTrigger, |
There was a problem hiding this comment.
The good news is the next major is EOM. The bad news is this was poorly designed so there is no way to avoid it being breaking. Java objects with builders should always have a private constructor for exactly this reason (and because the ergonomics of multiple input String's in a row is 🤢 ). While you're making a breaking change anyway, I'd go ahead and recommend making this constructor private.
|
Going to hold on this PR for ~ 2 weeks until we can make breaking changes. Work tracked in DEVSDK-3018 |
2 participants
Why?
We're working on surfacing more information to users around what their integration does when handling events. The first step of this is to tie subsequent API requests to the act of event processing. This PR adds a header to do just that.
What?
preparerecipe to justfile to aid automationStripe-Request-Triggerheader in event helpersSee Also