#vale-events-list

1 messages · Page 1 of 1 (latest)

celest abyssBOT
tidal verge
#

@mint shoal Hello! I'm going to need a lot more specific information to help you

#

vale-events-list

mint shoal
#

Sure let me know what you need

tidal verge
#

Hard to say unfortunately. Right now it's all really vague without much details unfortunately. I need you to be really clear about what you're doing, how you're debugging, what the issue is, what you see, etc.

mint shoal
#

Sure let me get you one specific example of a connected account that we missed events for

tidal verge
#

(Try to collect and write a clear summary all in one mesage)

mint shoal
#

acct_1MrjkUHZeffn7gyb
On 2023-10-11 13:40:45 we did a request to list all events starting after evt_1O02LbHZeffn7gybVeBHe2tC (most recent event we had previously fetched). The response included the range from evt_1O02eWHZeffn7gybCOPGtwQf to evt_1O02ViHZeffn7gybscojNOLg. We did multiple requests after this, always using the latest event from the previous request as the starting_after point, but I think this is the one to blame.
We later found that cus_OndvEudRX3STgX had invoice and subscription events happening a couple of seconds before that request that were never listed in that response or any of the following ones:

evt_1O02eXHZeffn7gybkLungYoG
evt_1O02eXHZeffn7gybcdTritws
evt_1O02eXHZeffn7gyb3DZoVFkc
evt_1O02eYHZeffn7gybeQnwYRNn
evt_1O02eYHZeffn7gybznN4RAMN```
A couple of days ago I fetched all events available for this account and they showed up.

We were assuming that every new event would be appended to the stream, and by listing events using the starting_after filter with the latest event we fetched we wouldn't be missing any.
tidal verge
#

Okay I'm going to try and debug this but I'm really confused by your wording about "appended". Like our API returns most recent first, so technically new Events are prepended not appended

#

The way you're supposed to ingest Events is to start without starting_after and paginate until you get one id you already saw no?

tidal verge
#

Like you said

2023-10-11 13:40:45 we did a request to list all events starting after evt_1O02LbHZeffn7gybVeBHe2tC
That specific Event has a created set to 2023-10-11 13:21:11 / 1697030471

One of the Events missing you mentioned is evt_1O02eXHZeffn7gybkLungYoG and it has created set to 2023-10-11 13:40:40 / 1697031640
So when you listed Events after that one you would never get the Event that was created later

mint shoal
tidal verge
#

Ah okay I see what you really meant. Sorry getting confused with the wording and this can be near impossible to debug

mint shoal
#

Yeah no worries

tidal verge
#

So you are saying you got evt_1O02LbHZeffn7gybVeBHe2tC in a previous batch and on 2023-10-11 13:40:45 you started a brand new list Events call without starting_after and expected evt_1O02eXHZeffn7gybkLungYoG in that page and never saw it?

#

Looking at it, the Events all seem to have happened at the exact same second so I wonder if you had some race condition but thos was also weeks ago

mint shoal
tidal verge
#

OOC why are you doing this instead of a webhook endpoint?

mint shoal
#

We've been doing this since forever (ProfitWell). We built two integrations with Stripe already, before and after the events expired after 30 days, and changing the way they work now would be massive.

tidal verge
#

yeah that's fair but that's a pretty sub-par way of integrating and it likely means an insane amount of GET calls overall for accounts that never need it

#

But okay I found that request you made at that exact second. The first Event was evt_1O02eWHZeffn7gybCOPGtwQf like you said but the last Event of the page was another one req_SaetJ3zRssolgJ not the one you said

#

You seem to be making recurring GET requests every 10/15 minutes (which is something I'm sure our team has told you to change in the past) and so I see you made another request on 2023-10-11 13:52:28. Were the Events there in that call?

mint shoal
#

Nope. The following request only returned one event (evt_3O02pSHZeffn7gyb01qf5UVu)

tidal verge
#

I mean it did not

#

Sorry it's important to be crisp here, you're mixing things up unfortunately. You are explicitly calling the List Events API and passing limit: 100. So you don't get one Event, you get a full page.

#

Maybe your own code ignores what you have already seen, but that's important to separate what your own code does from what our API does. I'm looking at our raw logs and we definitely returned 100 Events in that subsequent list call

mint shoal
#

Sorry, yeah. We stored 1 new event from the following request

tidal verge
#

Okay so you are saying those events exist but are never returned by our API at all even if you were to paginate their Events right now?

mint shoal
#

I know they are returned by the API now, but they were not at the time of the original request

tidal verge
#

But I asked you if they were returned at the next request and you said no

#

Are you saying that on 2023-10-11 13:52:28 which is a full 11.5 minutes later they were still not returned?

mint shoal
#

That I'm not sure. It is possible that we're looking for the last event we fetched in the previous request and only processing what's more recent than that. Could it happen that those events are present in the response but show up as less recent?

tidal verge
#

I don't really know what those words could mean unfortunately. This is up to your own code.
The best option is for you to run a one-off script, paginate all Events until after those Events and log clearly their order + id + created and then try and figure out if they appear before or after evt_1O02LbHZeffn7gybVeBHe2tC

mint shoal
#

I should be able to check that. Give me a sec

#

This is the order of events listed a couple of days ago

evt_3O02pSHZeffn7gyb01qf5UVu <- second request (most recent)
evt_1O02eWHZeffn7gybCOPGtwQf <- last event on first request
evt_1O02eYHZeffn7gybeQnwYRNn <- missing
evt_1O02eYHZeffn7gyboytjoAyS
evt_1O02eYHZeffn7gybznN4RAMN <- missing
evt_1O02eYHZeffn7gybfV7iiVP8
evt_1O02eWHZeffn7gybDUyZCQ26
evt_3O02eSHZeffn7gyb04gIv1AY
evt_3O02eSHZeffn7gyb0ipGTvSA
evt_1O02eXHZeffn7gybkLungYoG <- missing
evt_1O02eXHZeffn7gyb3DZoVFkc <- missing
evt_1O02eXHZeffn7gybcdTritws <- missing
evt_1O02eWHZeffn7gybdrhXPqwh
evt_3O02eSHZeffn7gyb0UJ8lSFy
evt_1O02eWHZeffn7gybbsHvkzly
evt_1O02dxHZeffn7gybX29JErpb
evt_1O02LbHZeffn7gybVeBHe2tC```
#

I only searched for the two reference points (evt_1O02eWHZeffn7gybCOPGtwQf and evt_3O02pSHZeffn7gyb01qf5UVu) and events for the customer that we identified as missing events, so there could be others in between

tidal verge
#

yeah that helps but that's still half of what we'd need I'm sorry

#

My advice is this: Write a one-off script that will list All Events for that specific connected account. As you paginate, properly log the index of the current Event, its id, its created and its type. Don't do just 100, do enough to get past October 11 so that we can see the exact raw dump of everything

And then explain which Events you did not get last time (which is what you're showing in that dump above). This should definitely be impossible so there's definitely a bug here

#

Do all that work, properly log it all and the exact time of your requestsand then reach out to our support team for them to investigate: https://support.stripe.com/contact

mint shoal
#

This is very helpful. Thank you.

I'll get back to my team with this and we'll reach out to support with more info

tidal verge
#

Sure thing! your last example is definitely worrying and it looks like a weird race condition with Events generated at the same second