Proposed new feature or change
ExponentialDelayMiddleware computes the backoff and pushes a DelayEnvelope, but the actual delaying is on the adapter (its docblock says so). Problem: no way to know whether an adapter honors it. Redis and the in-memory adapter just ignore DelayEnvelope, so the message comes back right away - no backoff, just instant retries. AMQP delays fine.
Same story as status() before #272. #191 listed both delay and status as adapter features; #272 did the status half, delay's still open.
Proposal: add hasDelaySupport(): bool, like hasStatusSupport(). Then the middleware can fall back / warn instead of silently dropping the delay.
Ok to go the same route as #272? Happy to PR it - core + redis/amqp.
Proposed new feature or change
ExponentialDelayMiddlewarecomputes the backoff and pushes aDelayEnvelope, but the actual delaying is on the adapter (its docblock says so). Problem: no way to know whether an adapter honors it. Redis and the in-memory adapter just ignoreDelayEnvelope, so the message comes back right away - no backoff, just instant retries. AMQP delays fine.Same story as
status()before #272. #191 listed both delay and status as adapter features; #272 did the status half, delay's still open.Proposal: add
hasDelaySupport(): bool, likehasStatusSupport(). Then the middleware can fall back / warn instead of silently dropping the delay.Ok to go the same route as #272? Happy to PR it - core + redis/amqp.