#Nukesforbreakfast
1 messages ยท Page 1 of 1 (latest)
You mean the response your server sends back to stripe, as visible in the developer dashboard?
Correct. It starts an AWS step function execution and the response contains the execution ARN. I'm looking to grab that ARN in order to use it to look up the step function results in integration tests.
There's no other way to inspect or retrieve that, no -- just the Developer event logs in your dashboard for debugging purposes. I'd suggest instead that you consider updating the relevant object to set values you need in metadata
Then you can get that later by retrieving the object
ok. In this case the ARN isn't known until after the execution is started, and thus after the objects are already created in Stripe.
also, not every event object returned has the ability to set metadata
a good example of this is the account.application.deauthorized event. https://stripe.com/docs/api/events/types#event_types-account.application.deauthorized
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
You can update metadata on objects whenever you like
oops, linked the wrong event.
sure, but it won't be present in the webhook right? For example payment_intent.succeeded.
If the metadata is set on the payment intent it would be, sure
right, but I don't have the ARN data to set until after the webhook starts processing in this case.
How does accessing the response body help you solve this?
Instead of say updating the payment intent to set that metadata
I'm essentially trying to find workarounds for the issue I ran into in a prior thread: #dev-help message
I need to distinguish between an event triggered on one branch of code under test versus another. Since it appears I can neither:
- target an event at a specific webhook endpoint nor
- generically add metadata to all events to specify their source
it's difficult to test properly.
I can look up the webhook endpoint in use for a given branch of code reliably, which accessing the response body would allow me to access the identifier of the started execution reliably, thus I can easily describe the execution state and validate in the test that the step function processed the event as expected.
Hey I am catching up here. Would there be a way to log the response that your server is sending as it is responding?
From a Stripe perspective, we are just sending you events about objects on our side, those objects don't really have a concept of your code or what branch of it was used to create that object
Right and that's the rub. Since I can have different step functions set up in parallel in nonprod for each in flight branch, and I can't target triggered events to a specific endpoint, and the ability to add metadata is not consistent across all events, it's turning out to be more complicated to properly test.
The main issue is I have a check to ensure I don't process the same event twice and since all step functions get the event, it's a race to see who processes it first.
I guess I'll have to set up a test fixture on a case by case basis instead and make accommodations for each event type I use.
The only way to differentiate it looks like is via metadata or, in the case of account.application.deauthorized is the application name.
It would be extremely helpful if there was a way in test mode to attach common metadata to all API requests that propagated to all objects and events created subsequently from that request.
Much easier to code up reusable fixtures that way.
Would it be possible for your code to record the IDs of the requests that it makes along with your version? https://stripe.com/docs/api/request_ids
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
I can put in a feedback request for that
Hi there ๐ taking over, as my colleague needs to step away
You can't set the Request ID unfortunately.
Yeah, I don't think that will work given I need a value defined before I send a request that triggers the event.
So it keeps coming back to metadata for the objects that support it, and for those that don't I don't know what to do.
Wait, so the problem is that your webhook handler(s) is/are set up in such a way that multiple things might be changing state at the same time when a webhook is received?
My problem is I stand up a parallel copy of the webhook receiver any time someone opens a PR, ideally to test those changes in isolation. This includes a new webhook endpoint targeting a unique URL.
However, since I can't configure stripe to fire events triggered by my test suite at a specific webhook endpoint, all set up endpoints get the events simultaneously. I need to differentiate between what source triggered a given event to prevent the other endpoints from processing the event.
Which seems like metadata is the only way. But metadata isn't transmitted for every event type I listen for.
Do you have an example of an event you're currently processing that doesn't have metadata in either the Event's object or one of the myriad of nested objects?
I would not be surprised if there is one, I'm just struggling to think of one
Yes
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Taking a look now
Ahhhh, okay. And it's probably not feasible to programmatically update the webhook endpoint to stop listening for that specific type of event?
not really. I have the configuration of the endpoints defined in IAC using Terraform. I'm trying to test the deployed configuration.
Gotcha. Yeah, in the case of objects without metadata you would likely need to have an alternative plan for gauging whether or not to process the event on an event-by-event basis
that's what I thought. It would be a useful feature to be able to set metadata in the request somewhere and have it propagate to all objects and events created by that request.
Similar to something like the AWS Terraform provider's default_tags block, which propagates all tags defined at the provider level to all child resources created in AWS: https://registry.terraform.io/providers/hashicorp/aws/latest/docs#default_tags-configuration-block
this might be predicated on either event objects themselves having metadata, or all stripe objects adding a metadata hash.
I will double-check to make sure that Pompey put in that request and then add a +1 to it, because yeah obviously there s real need
either that or somehow be able to restrict which endpoints send test events based on the triggering source. For example, some argument to the CLI's stripe trigger where you can specify a specific webhook endpoint to send the resulting events to.
Yeah, that might be even better. I'll add both to the docket for the product team to look over and triage