nerder

[sonic anvil]

Hello! If you have a live mode Connect Webhook Endpoint it will receive Events from Connected accounts in both live and test mode, yes.

[smoky cradle]

ok, so I need to have a middleware in place that checks in which environment i am before handling the event?

I have in place something like this, but i'm not sure if makes sense to have it:

  async use(req: Request, res: Response, next: () => void): Promise<void> {
    const liveMode = req.body.livemode;

    const isProdEvent = liveMode;
    const isDevEvent = !liveMode;

    if ((isProdEvent && isDev()) || (isDevEvent && !isDev())) {
      this.logger.warn('Event received from the wrong environment');
      throw new BadRequestException('Event received from the wrong environment');
    }

    next();
  }

[sonic anvil]

I don't think it makes sense to throw an exception; receiving both test and live mode Events is expected. But yes, you need to route the Events to the appropriate environment as needed.

[smoky cradle]

ok, maybe just skip it then

since we are here, discussing webhook I would like to double check on thing also

i'm about to migrate away from a legacy webhook handler to a new one in my code

my idea to avoid downtime is to setup both webhooks in Stripe

one will fail always, because the API key stored as a secret in my environment will not be valid, while the other will succeed

than i will update the API key to the new webhook and then redeploy my service

as soon as it goes up, the old webhook will not longer work and the new one kicks in

is this making sense?

What should i do with all the retry attempts that will be pending?

[sonic anvil]

Generally we recommend you update your code to handle both the old and new version of the Events, then once you're confident the new versions are being handled correctly you can make the switch on your end and then remove the old Webhook Endpoint.

We do not recommend that you respond with failure as that will, as you said, make a lot of retries pile up.

You should accept both versions and queue/log/discard the ones you don't want as needed on your end as you migrate.

[smoky cradle]

umm, ok

you mean that i have both webhook endpoints up at the same time?

but maybe with a simple skip for everything?

[sonic anvil]

Yep.

I'm not sure what you mean by "simple skip" though?

[smoky cradle]

simply respond 204 for every request

but i'm not sure it works

the point is, i need to have both webhook handlers up at the same time, but they do basically the same thing, so imagine when i receive a customer.created if both the webhooks are up they will create the customer 2 times in my DB

[sonic anvil]

Right, you need to ignore one of the Events. You start by ignoring the new Events, just make sure you're getting them. Then you do a dry run where your logic runs but doesn't actually write to the DB, it just logs what's happening to confirm it works. Then you make the actual switch.

Or you can write to a dev DB.

Whatever makes sense for your system.

[smoky cradle]

but in this scenario there will always be a moment in which both will be up and writing

ah no ok!

i follow now

in the same atomic commit I'll need to make one skip and the other actually do the write!

[sonic anvil]

Yep.

[smoky cradle]

will be like this:

1. new webhook deployed, accepts events but returns 204 for all
2. old webhook, accepts events and perform business logic
3. configure both webhooks in Stripe Dashboard
4. see that events are received in both, they both works
5. push a new commit that that make the old one skip everything and the new one write
6. deploy both new and old webhook
7. switch off the old webhook

[sonic anvil]

Yep, that sounds like a good plan!

[smoky cradle]

thank you so much for your help

last question, since i've already created the new webhook handler in prod

and now all the events are failing

is ok if i just remove it to avoid receiving the retry?

[sonic anvil]

Yep.

[smoky cradle]

ok, i'll delete is, ship the new code that skips properly

sorry for being so pedantic eheh

is a quite delicate operation 😸

[sonic anvil]

No worries! I totally understand wanting to be careful and do things right!

Best to be sure and go slow instead of going fast and breaking something. 🙂

[smoky cradle]

thank you!

for instance, there is no way to create a new endpoint that starts disabled right?

because I need to have the webhook key before

but I can eventually create it, and disable it very fast

and if couple of events sneak in I can wait couple of hours to avoid the retry

or i can eventually avoid validating the signature entirely

[sonic anvil]

You can't create it as disabled, but you could set it to only listen to one Event you never generate, then switch it to the Events you want when you're ready.