queue handlers have exactly the same limits (cpu time etc) as a fetch
queue
MM
env.YOUR_BINDING_NAME.send() (and passing in env as an arg?). Posting your code would help to confirmMMObject.keys(env) and paste the output? DM me if you prefer.MMMMM
MM
E
batch object to know which Queue you're consuming from in that particular execution.EWorkers > Overview > (your worker) > Triggers > Queues (bottom of page)) or by removing it from the wrangler.toml configuration and publishing the changesEM.ack() on every message (or the entire batch) when handling it? .retry() would exist for the cases where you want to explicitly, negatively acknowledge.
this post; if no, reply with why! Keep in mind I am familiar with other messaging systems; there’s not an agreed-upon approach here!MMM
YOUR_QUEUE.send(). In the longer term we’re exploring other on-ramps to support this nativelyMM
UUMUM
.ack() to make partial progress through a batch so that message is not retried if the handler errorsretry() or retryAll() on a message or a batch to force a retry, even if the handler returns successfully
DUD
KED
E
env.YOUR_BINDING_NAME.send()envObject.keys(env)batchWorkers > Overview > (your worker) > Triggers > Queues (bottom of page)wrangler.toml.ack().ack().retry()YOUR_QUEUE.send()retry()retryAll()export default {
...
async queue(batch: MessageBatch, env: Env, ctx: ExecutionContext) {
if (batch.queue === 'my-first-queue') {
doSomething()
} else if (batch.queue === 'my-other-queue' {
doSomethingElse()
}
...
},
};