Couple queries: Any plans to add a `Message.deadletter` method? I have some use cases where I _know
Couple queries:
Any plans to add a
Message.deadletter method? I have some use cases where I know the message will always fail and it needs manual triage.
It'd be great to have redrive functionality to move messages from the deadletters to processing queue once any issues with the deadletters have been resolved (e.g. temp outage). AWS SQS has similar functionality https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-dead-letter-queue-redrive.htmlLearn how to configure a dead-letter queue redrive in Amazon SQS - ...
Learn how to configure an Amazon SQS dead-letter queue redrive to move messages from a dead-letter queue to a source queue or other standard queue.
16 Replies
Also, are there plans to suppport passing a
Message into an RPC Worker?I don't see wrangler.toml's equivalent of
[[queues.consumers]] referenced in https://developers.cloudflare.com/workers/configuration/multipart-upload-metadata/#bindings -- is that intentional? if so, how does one configure a Worker uploaded from the API to be a queue consumer? I've added "type": "queue" in my bindings metadata, but that only seems to register the worker as a queue producerIt's done via this API: https://developers.cloudflare.com/api/operations/queue-v2-create-queue-consumer
Cloudflare API Documentation
Interact with Cloudflare's products and services via the Cloudflare API
ah, I forgot to mention that I was trying to create queue consumers for user-uploaded scripts. I filed https://github.com/cloudflare/workers-sdk/issues/6758
Via WfP?
yep
Can you not just have the dispatcher call the user Worker?
Also, I don't think WfP actually supports any kind of events other than one's sent by the dispatcher atm
that’s the direction I was heading, by passing messages received in the dispatcher’s queue consumer to the user worker via a POST fetch. but how can the user worker call message.retry(), since the messages will be serialized into JSON?
It returns an object back with which messages to retry/ack
it is just me, or does
delaySeconds no longer work?
it looks like it stopped working on 9/17 around 18:00 UTCits still listed on the dev docs still, so it wasnt removed, was it?
please ping me if you reply 🙂
im currently getting ratelimited by an external service because things that are supposed to be delayed (using queues) are all getting run at once
Hey the time between my message getting sent to queue -> being processed by my working is taking a few seconds before it even starts being processed. Anyway to speed this up?
Seems 1000/1s is the minimum value in dashboard UI and cant be set via wrangler.toml
Hey folks, fresh Queues user here. I am having issues with queue messages not being processed after they are sent back for a
.retry(12 hours), and I can't figure out whether I've mis-configured something or am hitting an edge case.
I produce queue messages in batch from my Pages website, it is basically a set of payloads for emails to be sent out, some to be sent out immediately (message has a field after: now.toISO()), and some upon delay (message has a field after: remindOn.toISO(), typically 3-5 days from now). The are 0-3 batches of these messages per day sent out worldwide, as in these are not high volume.
The messages are received by a Workers consumer, generated from a standard Cloudflare workers template. The relevant bit is the .retry({delaySeconds: X}) of messages which should not be processed yet: if the after field of the payload message is in the future, I am sending the message back for a retry of up to 12 hours, because it is the documented maximum I found.
What happens, is that the messages I've sent for a long retry don't seem to process until there is a fresh new unrelated message added to the queue, which seems to trigger the re-processing of .retry()-ed messages. This doesn't seem to happen globally either, but rather per region, as in that "fresh new unrelated message" will only trigger the re-processing of geographically proximate messages. E.g. I had somebody in Germany visit my website on Sept 11 and fill out the booking form for Sept 16 lesson; they received the "immediate" messages, but the "reminders" got stuck in limbo until Sept 11 until a completely different person somewhere in Russian filled out the form which triggered new messages to be added to the queue.