Describe the solution
Problem Description
Currently, when working with Cloudflare Queues in Workers, queue names are only available via batch.queue in the queue consumer handler. This creates a maintenance issue when queue names are dynamic (e.g., environment-specific like email-queue-staging, email-queue-pr-123) because developers must either:
- Hardcode queue names in switch statements (brittle)
- Use pattern matching/normalization (complex and error-prone)
- Maintain separate mappings (duplicated configuration)
Current Problematic Code
// ❌ Hardcoded queue names - breaks with dynamic environments
switch (batch.queue) {
case 'email-queue': // What about email-queue-staging or email-queue-pr-123?
case 'stripe-customer-queue': // What about stripe-customer-staging-queue?
}
// ❌ Complex normalization required
function normalizeQueueName(queueName: string): string {
if (queueName.startsWith('email-queue')) return 'email-queue'
if (queueName.includes('stripe-customer') && queueName.includes('queue')) {
return 'stripe-customer-queue'
}
return queueName
}Proposed Solution
Expose a name property on Queue bindings so developers can reference the actual configured queue name from the binding itself:
interface Queue<Body = unknown> {
name: string; // NEW: The queue name from wrangler.jsonc
send(body: Body, options?: QueueSendOptions): Promise<void>;
sendBatch(messages: Iterable<MessageSendRequest<Body>>, options?: QueueSendBatchOptions): Promise<void>;
}Desired Usage
// ✅ Clean, maintainable code that works with any queue naming
switch (batch.queue) {
case env.EMAIL_QUEUE.name: // Automatically resolves to actual queue name
// Handle email messages
break;
case env.STRIPE_CUSTOMER_QUEUE.name: // Works regardless of environment
// Handle stripe messages
break;
}Benefits
- 🔧 Maintainable: No hardcoded queue names
- 🌍 Environment-agnostic: Works with staging, production, PR previews
- 🛡️ Type-safe: Compile-time validation of queue references
- 📝 Self-documenting: Clear relationship between bindings and consumers
- ⚡ Simple: Eliminates need for complex normalization logic
Configuration Example
With this feature, env.EMAIL_QUEUE.name would return "email-queue-staging", making the consumer code environment-independent.
Alternative Considered
Using pattern matching (current workaround), but this approach:
- Requires maintaining separate normalization logic
- Is error-prone with complex queue naming patterns
- Duplicates queue naming knowledge across codebase
Use Cases
- Multi-environment deployments (dev/staging/production)
- PR preview environments with dynamic queue names
- Microservices with tenant-specific queues
- Testing environments with isolated queues
Describe the solution
Problem Description
Currently, when working with Cloudflare Queues in Workers, queue names are only available via
batch.queuein the queue consumer handler. This creates a maintenance issue when queue names are dynamic (e.g., environment-specific likeemail-queue-staging,email-queue-pr-123) because developers must either:Current Problematic Code
Proposed Solution
Expose a
nameproperty on Queue bindings so developers can reference the actual configured queue name from the binding itself:Desired Usage
Benefits
Configuration Example
With this feature,
env.EMAIL_QUEUE.namewould return"email-queue-staging", making the consumer code environment-independent.Alternative Considered
Using pattern matching (current workaround), but this approach:
Use Cases