Skip to content

refactor: rename delay label to x_delay to avoid conflict SmartRetryMiddleware - #54

Merged
danfimov merged 1 commit into
taskiq-python:masterfrom
MikhailWar:fix/conflict-middleware-retry-delay
Sep 16, 2026
Merged

danfimov merged 1 commit into
taskiq-python:masterfrom
MikhailWar:fix/conflict-middleware-retry-delay

Conversation

@MikhailWar

@MikhailWar MikhailWar commented May 13, 2026

Copy link
Copy Markdown
Contributor

Fix label collision between broker and SmartRetryMiddleware

Problem

When configuring a retry delay on a specific task, the task is never retried:

  broker.register_task(
      task,
      retry_on_error=True,
      max_retries=10,
      delay=15,  # retry interval
  )

The delay=15 label gets embedded into every message for that task. AioPikaBroker reads the same delay
label and tries to route the message through a delay queue. Since no delay_queue or
delayed_message_exchange_plugin is configured, the broker raises:

IncorrectRoutingKeyError: Delay requested but no delay queue or
 delayed-message-exchange is configured in the broker.

Using SmartRetryMiddleware(default_delay=5) works fine because the default is handled by the middleware
itself and not stored as a task label.

Fix

Rename the broker's label from delay to x_delay. The x_ prefix follows the RabbitMQ convention for custom
headers and makes it clear this label belongs to the transport layer, not to retry logic.

Migration

# before
await my_task.kicker().with_labels(delay=5).kiq()

# after
await my_task.kicker().with_labels(x_delay=5).kiq()

@danfimov
danfimov force-pushed the fix/conflict-middleware-retry-delay branch from a6c2e4f to 370e3c5 Compare September 16, 2026 14:39
@danfimov
danfimov merged commit 176edd3 into taskiq-python:master Sep 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants