dapr / dapr/components-contrib
ttlInSeconds in bindings.rabbitmq failing
- Dominant language
- Go
- Stars
- 602
- Forks
- 580
- Avg merge
- 4d 9h
- Merged PRs (30d)
- 6
Description
## Expected Behavior
I am trying to bind a queue in rabbit mq using a component attaching the component below
`apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: wait-for-thirty-days
spec:
type: bindings.rabbitmq
version: v1
metadata:
- name: queueName
value: "wait-for-thirty-days"
- name: host
value: amqp://guest:guest@rabbit-mq:5672
- name: durable
value: "true"
- name: maxPriority
value: "10"
- name: direction
value: "output"
- name: ttlInSeconds
value: "2592000"`
i have created the queue in rabbit mq with the correct ttl, i was expecting the queue to bound
## Actual Behavior
i am getting the following error
` time="2024-04-25T11:40:10.503551172Z" level=fatal msg="Fatal error from runtime: process component wait-for-thirty-days error: [INIT_COMPONENT_FAILURE]: initialization error occurred for wfe-thirty-days (bindings.rabbitmq/v1): [INIT_COMPONENT_FAILURE]: initialization error occurred for wait-for-thirty-days (bindings.rabbitmq/v1): Exception (406) Reason: \"PRECONDITION_FAILED - inequivalent arg 'x-message-ttl' for queue 'wait-for-thirty-days' in vhost '/': received '-1703967296' but current is '2592000000'\"" app_id=journey-builder instance=135652a5087c scope=dapr.runtime type=log ver=edge`
i think there is some overflow happening
## Steps to Reproduce the Problem
- i spun up a rabbit mq container
- created the queue with ttl and dead letter
- defined the dapr compnent
- ran the dapr pplication
Contributor guide
Research direction
Start with the bindings.rabbitmq component's handling of the ttlInSeconds metadata and reproduce the queue declaration using the configuration in the issue against RabbitMQ. Done means a 2,592,000-second TTL is passed without overflow and an existing queue with that TTL binds successfully.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, rabbitmq
- Domain
- backend, distributed-systems
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100