Repository navigation
Adapter delay support flag #305
Description
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.
Activity
KalimeroMK commentedon Oct 12, 2026
Still the case on master (
7c79c3b).DelayEnvelope::getDelaySeconds()has no callers outside its own unit test, and nothing insrc/orstubs/readsyii-delay—ExponentialDelayMiddleware:57only produces the envelope.SyncQueueProducer::push(new DelayEnvelope($m, 2.0))returns in 0.0011s andQueueConsumer::run()overDelayEnvelope($m, 5.0)finishes in 0.0000s; both handle immediately, with no log line and no exception.hasDelaySupport()would at least let the middleware warn instead of dropping the backoff silently.