Event Streams are now triggering the webhooks 3 times (confirmed-false, confirmed-false, and confirmed-true).
But the expected behavior is to initiate only two-event confirmed-false and confirmed-true.
I have logged the number of triggers. You can see that the same stream is triggered for two times with confirmed-false
When can we expect to get this issue fixed? It is a problematic for our usecase
this could happen in the case of a reorg? you can receive the same unconfirmed event twice in that case? it is exactly the same unconfirmed webhook request?
It is a same request with same stream ID. It is happening everytime for me now. Reorg will be a rare case right ?
yes, reorg will be a rare case
it is the same webhook request? with the same signature?
I am getting this behavior every time now. And if it is a block reorg, the block number should be different right? But it is the same right now
Where can I get the signature ? The webhook interface doesn’t have any signature property
the signature is in the http header of the received webhook request
can you paste the stream id?
is there a delay of ~1 minute between those 2 requests? could it be a failed request that is replayed?
Event 1: 96404c21-b55f-4c86-b274-b5f9391227ca
Event 2: 151b0e91-c3ec-48fb-a914-558e5808a157
it is exactly 1 minute delay between those 2 unconfirmed events?
Not sure, but it is being triggered within 30s to 1 minute timeframe
if it is 1 minute delay it could be if the webhook request didn’t receive status code 200 for the first unconfirmed request.
if you look in the stream id stats, you see failed webhook requests?
if you look in history you see some failed webhook requests?
The stream request is failed when the second time it arrives. we will throw an error if certain condition not met.
But why we need to send a 200 status code within 1 minute. Each and every application might have a different event processing time based on the bussiness requirments
It was not the same behaviour previously. Earlier, if we throw an error, the stream will retry exponentially for serveral times
if the webhook request doesn’t receive a status 200 ok fast, then it will retry, you could still get exponential requests now if it doesn’t return status code 200, it just takes more time for the other webhook requests to arrive for the other retries
can you check the stream stats and the history for your account?
if the webhook request doesn’t receive a status 200 ok fast, then it will retry, you could still get exponential requests now if it doesn’t return status code 200
Why SDK is sending another retry request within a 1-minute window? Retry webhooks request needs to be sent only if there is any error or a timeout error right? It doesn’t matter how long the webhook API endpoint is processing. If a endpoint doesn’t throw any error, it is not correct to consider the API request is failed
can you check the stream stats and the history for your account?
I can see the bunch of errors/failed webhooks in my streams dashboard
there is a timeout value for that webhook request, if it doesn’t receive a response in a specific time limit then it could consider it as a failed webhook request, you should see the exact reason for the webhook failed requests in the history for each failed webhook request
Yes, I can see the reason now.
But why Moralis is just waiting for 1 minute to conclude the request is timed out ? It is not the case earlier
The webhooks are pointing towards our background jobs server and it will do some heavy operations. So the timeout should not be applied for such cases. The timeouts are usually considered as failure if the API itself throws an timeout error.