Handling Queue Timeouts in Delayed Game Webhook Delivery

A worker delivering delayed game-event webhooks should acknowledge a queue message only after the delivery attempt reaches a durable outcome. The article argues that a timeout must lead to a retryable state rather than a lost cleanup job or an unbounded retry loop. It recommends separating the queue lease from the HTTP request timeout, recording an attempt before sending the request, and making the receiving service idempotent. Because a timeout only shows that the worker stopped waiting, it cannot confirm whether the remote side applied the change. The proposed design classifies each result as delivered, retryable, or terminal, and acknowledges the message only once that state is stored.