CD
Cloudflare Developers•2w ago
sup filistine

Queue retries not happening consistently with either message or global retry_delay wrangler setting

i saw this same behavior yesterday. curious what’s up. i didn’t pass an explicit retry delaySeconds for the message, just an empty .retry(), and was hoping it will respect the retry_delay configured under the wrangler consumer section. will do some more tests today
1 Reply
sup filistine
sup filistineOP•7d ago
@Pranshu Maheshwari my account ID is c0ff9f2cf8ab2c3e11611df68fd4ac96. This is from my zones page. And the queue name is complaints-publisher. You had offered me some help in another queue issue last week, but that one became obsolete for me and i am experiencing this one, but only in one of my envs, sadly production env. Launched the feature today and would be great to get to the bottom of why the retries are not happening. To elaborate: 1. Retries are never happening on the 30s interval that i set per message with .retry before exiting the consumer. They are happening haphazardly, oftentimes when newer messages arrive, other times, not at all. 2. With the retry_delay set to 300, i have seen messages retry themselves at 600s, not sure that was a coincidence because exactly then, new messages had arrived. My consumer settings in wrangler are: 
[[queues.consumers]]
queue = "complaints-publisher"
dead_letter_queue = "complaints-dlq"
max_batch_size = 10
max_batch_timeout = 5 # optional: defaults to 5 seconds
max_retries = 3
# max_concurrency of 1 should be sufficient
max_concurrency = 1
# retry_delay comes to use for uncaught exceptions
retry_delay = 300
[[queues.consumers]]
queue = "complaints-publisher"
dead_letter_queue = "complaints-dlq"
max_batch_size = 10
max_batch_timeout = 5 # optional: defaults to 5 seconds
max_retries = 3
# max_concurrency of 1 should be sufficient
max_concurrency = 1
# retry_delay comes to use for uncaught exceptions
retry_delay = 300
To be sure, when i call .retry on a message, i dont call .ack. i think i am understanding the usage correctly. I thought retry without any arguments will make use of retry_delay in wrangler.toml but i am not 100% sure about it, given i read that it applies for uncaught exceptions. My consumers are gracefully quiting because of a Promise.allSettled The dead letter queue is also not filling up, not sure whats up with that because when i did get lucky at one point and retries started happening on new messages, they didnt enter the DLQ after the failed attempt #4. My bad as far as this report in that, i mistakenly put 30,000 in delay seconds on individual message, thinking i was working with milliseconds. i will adjust that and see where it leads. Yep, its working well now. Closing this thread.

Did you find this page helpful?