#Nukesforbreakfast

1 messages ยท Page 1 of 1 (latest)

rough badgeBOT
sinful crag
#

You mean the response your server sends back to stripe, as visible in the developer dashboard?

slender berry
#

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.

sinful crag
#

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

slender berry
#

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

sinful crag
#

You can update metadata on objects whenever you like

slender berry
#

oops, linked the wrong event.

slender berry
sinful crag
#

If the metadata is set on the payment intent it would be, sure

slender berry
#

right, but I don't have the ARN data to set until after the webhook starts processing in this case.

sinful crag
#

How does accessing the response body help you solve this?

#

Instead of say updating the payment intent to set that metadata

slender berry
#

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:

  1. target an event at a specific webhook endpoint nor
  2. generically add metadata to all events to specify their source

it's difficult to test properly.

slender berry
# sinful crag How does accessing the response body help you solve this?

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.

sand dome
#

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

slender berry
#

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.

sand dome
#

I can put in a feedback request for that

slender berry
#

Let me see.

#

Am I able to set the request ID?

calm plank
#

Hi there ๐Ÿ‘‹ taking over, as my colleague needs to step away

You can't set the Request ID unfortunately.

slender berry
#

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.

calm plank
#

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?

slender berry
#

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.

calm plank
#

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

slender berry
#

Yes

calm plank
#

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?

slender berry
#

not really. I have the configuration of the endpoints defined in IAC using Terraform. I'm trying to test the deployed configuration.

calm plank
#

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

slender berry
#

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.

#

this might be predicated on either event objects themselves having metadata, or all stripe objects adding a metadata hash.

calm plank
#

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

slender berry
#

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.

calm plank
#

Yeah, that might be even better. I'll add both to the docket for the product team to look over and triage