#k3davis - events

1 messages ยท Page 1 of 1 (latest)

runic stag
#

Interesting. Looking in to how to get this with the API

cinder goblet
#

thank you

runic stag
#

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?

cinder goblet
#

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

runic stag
#

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?

cinder goblet
#

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

runic stag
#

Interesting. Trying to think of why this might not be working.

#

Checking in to if this might be test mode specific behavior

cinder goblet
#

ok

runic stag
#

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?

cinder goblet
#

instead of deliverysuccess = false or in addition to?

runic stag
#

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

late solstice
#

@cinder goblet ๐Ÿ‘‹ have you been able to make the call?

cinder goblet
#

sorry i'm still working on it, have to translate that request to the .net sdk

late solstice
#

all good, let me know if you need help

cinder goblet
#

ok. i did both, and it worked when i left off deliverysuccess = false but not with it

late solstice
#

can you confirm if you only get one event in the response (without delivery_success)?

cinder goblet
#

yes, i only get one event

late solstice
#

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

cinder goblet
#

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 ๐Ÿ™‚

late solstice
#

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"

cinder goblet
#

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

late solstice
#

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

cinder goblet
#

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

late solstice
#

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)

cinder goblet
#

understood. thanks very much for looking into it for me and for your insight into alternatives.

late solstice
#

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 ๐Ÿ™‚

cinder goblet
#

glad to be of any help. have a great day ๐Ÿ™‚