7 replies

Super cool. A few of questions:

Super cool. A few of questions:

1- Can we trigger it programmatically?

2- Do you plan to also allow purging based on message params? Like conditionally purge them?

Pranshu Maheshwari•3/27/25, 2:40 PM

You can do it programmatically. See the API docs here: https://developers.cloudflare.com/api/resources/queues/subresources/purge/methods/start/

Cloudflare API | Queues › Purge › Purge Queue

Interact with Cloudflare's products and services via the Cloudflare API

Pranshu Maheshwari•3/27/25, 2:41 PM

2. We are planning to add timestamp based purging (eg, purge messages received between Jan 1 & Jan 2). What do you have in mind though? Could you tell me more about your use case?

SaqibOP•3/27/25, 4:41 PM

I was thinking more of a particular value on the message. e.g., purge everything for a particular user — maybe they sent something wrong or want to send again.

SaqibOP•3/27/25, 4:42 PM

So basically purge everything received from a particular user between time x -> y

Pranshu Maheshwari•3/27/25, 6:05 PM

Gotcha, this makes sense! we're working on a few ways in which you can create one queue per user of your application (and then you could purge those queues)

Pranshu Maheshwari•3/27/25, 6:05 PM

too soon to provide timelines here, but I'll send you a note once there's something you can test out

SaqibOP•3/27/25, 9:31 PM

That'd be helpful. To extend previous use case, if something is wrong in data (a wrong param in message), then I can just do if x == certain_value, purge it. And sure, would be happy to test it out and give feedback.

Also, can we expect dynamic binding anytime soon? Abiity to get queues on-the-go instead of binding in wrangler.toml, perhaps something like DO stubs.

Pranshu Maheshwari•3/28/25, 3:53 PM

Dynamic binding isn't currently in the works. our current plan is way to create partitioned queues, by specifying an optional partition key when you send a message:
queue.send(message, { partitionKey: message.userId })queue.send(message, { partitionKey: message.userId })

all partitions would attach to the same consumer worker. so it would let you dynamically create one queue per user of your application

it's too soon to say for sure if this is exactly what we'll build, but the goal is to help you get some form of a queue on the go

Super cool. A few of questions:

Similar Threads

Similar Threads

Similar Threads