Ouch, for my requirements that means that I need 100% to prevent my server to spawn multiple workers for the same streamer, I can’t just rely on event deduplication then or it would be as complex or even more complex than having a stateful worker pool with mutexes. So I think I will just accept any event with valid headers and with a short timestamp (let’s consider events with a timestamp older than 10 minutes invalid like the docs states to mitigate replay attacks) , keep track of my active workers instead of the events and just make sure that I never have two workers performing the same job.
Thanks anyway, this is useful! As a suggestion, IMO things like this:
witch will retry with exponential backoff like 4/5? times before it gives up on a given message if it didn’t get a 2x. So in practice you should NEVER get a duplicate message ID. But you need to protect yourself in case a hacker does the replay attack
And in the example of a stream.online, you might get a second stream.online with a different message ID.
…should be in the EventSub docs. Because they are very useful when considering your architecture and if they were I wouldn’t be here wasting your precious time!
Thanks and also, this is offtopic, but I want to thank you also for your persistent work which has made our feedback heard and as a result we have the vod_offset for clips back, finally!
Thank you for everything! 