#mclowrider_best-practices

1 messages · Page 1 of 1 (latest)

wanton larkBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1377967105307312269

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

steady sun
#

hi there!

charred oar
#

Hello!

steady sun
#

What do you mean by this?

be used as a sequence for when an object was updated

charred oar
#

An integration can ignore older updates if it has already processed a newer event

#

Per object that is, if that makes sense

#

As a mechanism to handle events arriving out of order.

steady sun
#

I'm sorry I don't follow.

#

can you share a concrete example?

charred oar
#

Sure

#

Recently we received two invoice events out of order. We received an invoice payment failed eventually after the invoice payment succeeded event

#

This can happen according to the docs

steady sun
#

yep

charred oar
#

We are thinking of the best way to handle this in our system

#

In that scenario we essentially renewed the customers access to our product then revoked it.

#

We want to fix this so it doesn't happen again

#

Could we use the timestamp of the invoice events in that scenario to determine order. So if we stored the invoice event timestamp in the payload we can ignore older invoice events

#

The AI assistant talked about a sequence number but I've never seen that.

steady sun
#

the recommended solution is when you receive an event, to make an API call to retrive the object. this way you can see its latest status. for example getting an event about a failed payment, but then when you retrive the payment with the API its status is actually succeeded

charred oar
#

That just narrows the possibility of a race condition but doesn't eliminate it?

#

With version/sequence/timestamp numbers we can ignore older events if we already processed the new state

#

Just checking if any such version/timestamp/sequence exist on Stripe objects/events as it would really make handling out of order a lot easier. Using that key integrations would be able to implement optimistic concurrency locking if that makes sense..

steady sun
#

yes I think you could use the event timestamp for this. otherwise there's no "sequence" you could use

charred oar
#

Is this the created timestamp on the event?

#

Or is the there an updated timestamp on every event object

steady sun
#

so what you are trying to do is not possible I think. instead you should do what I recommended earlier:

when you receive an event, to make an API call to retrive the object. this way you can see its latest status.

charred oar
#

Ok

#

It probably our biggest challenge with the Stripe integration

#

As we also have to consider rate limits on the API

#

Might be one to feedback to the product teams. An object version/sequence would really help to handle this without having to call Stripe back each time and potentially exhaust our API limit.

steady sun
#

yep, makes sense!

charred oar
#

Thanks soma. Not the answer I was looking for but at least I have a way forward.. Looking forward to an object version at some point 🙂

wanton larkBOT