#k3davis - events
1 messages ยท Page 1 of 1 (latest)
thank you
Did you eventually successfully get those events on a retry or have they never been successfully sent to you?
Do you have an example ID of an event that is not showing up?
i'm not expecting to see the ones that worked on a retry, but i do have an example that never delivered and isn't showing up, let me get that id
evt_1KvnFlFnSqw89al67wfYB1jG
Thank you, checking that event out.
Interesting, it looks like it is pending a resend which is one of the criteria for that parameter
Can you try directly retrieving the event by its ID with the API and see if that returns successfully?
it looks from the dashboard as though all retries are exhausted (especially since this is in test mode)
i will try to get the event directly
i retrieved the event from the api fine by id
pending_webhooks=1 but idk what else to look for here
Interesting. Trying to think of why this might not be working.
Checking in to if this might be test mode specific behavior
ok
Can you call the list endpoint again and pass created[gte]: 1651690129 and created[lte]: 1651690130 and see if you get that event back within the first page that way?
instead of deliverysuccess = false or in addition to?
Try it without first and then with both if you can
I am interested to see if it shows up in general and then if the delivery success parameter affects the behavior that you are seeing
@cinder goblet ๐ have you been able to make the call?
sorry i'm still working on it, have to translate that request to the .net sdk
all good, let me know if you need help
ok. i did both, and it worked when i left off deliverysuccess = false but not with it
can you confirm if you only get one event in the response (without delivery_success)?
yes, i only get one event
thnks, give me a few minutes to look at our logs
Okay I can confirm the same when I look at the logs so this seems like a bug on our end unfortunately. I'm not sure what's causing this so I'm going to flag internally.
I'd recommend to write it off as a quirk and ignore since it's all Test mode and shouldn't really matter
meaning you believe it works as expected with delivery_success in live mode?
sorry if i misunderstand
i'm ok writing off test mode quirks but i do need to know how it works in live mode ๐
I've never seen it not work so yes. but also I personally have ~never seen anyone use this feature beyond one-off recovery after their entire servers crashed for days
so we could switch to "what are you really trying to do"
i do intend to use it for one-off recovery after scheduled downtime.
maybe i need to look closer at the retry timeline in live mode
we retry for up to 3 days so you'd have to be hard down for a while
and honestly in that case, if it were me, I'd list all events and process the ones I have no records of
i agree that is simpler, but what i wanted was "all events for which there is a configured webhook" because i don't care about other events. but i could approach that another way i suppose.
i appreciate your input
I do think that filter works and I'm reporting it so that we dig into it, but yeah if it were me I'd ingest all events (or the relevant type(s) I want)
understood. thanks very much for looking into it for me and for your insight into alternatives.
of course and thanks for the debugging with me, it makes it crystal clear what is happening and will make it easier to debug for the product team too ๐
glad to be of any help. have a great day ๐