Updated changelog date

Author: maheshwarip

src/content/changelogs-next/2025-02-13-customize-queue-retention-period.mdx renamed to src/content/changelogs-next/2025-02-14-customize-queue-retention-period.mdx

@@ -3,7 +3,7 @@ title: Customize Queue message retention periods
 description: Customize the retention period for a queue, starting from 60 seconds to a maximum of 14 days.
 products:
   - queues
-date: 2025-02-13 12:00:00 UTC
+date: 2025-02-14 12:00:00 UTC
 ---
 
 You can customize a Queue's message retention period, starting from 60s to a maximum of 14 days.
@@ -16,7 +16,7 @@ With this update, you can retain messages for up to 14 days. Or if you want your
 
 You can customize the retention period on the Queues settings page on the dashboard, or using Wrangler:
 ```bash title="Update message retention period"
-$ wrangler queues update my-queue --message-retention-period 5d
+$ wrangler queues update my-queue --message-retention-period-secs 600
 ```
 
 This feature is available on all new and existing Queues. If you haven't used Cloudflare Queues before, [get started with our guide here](/queues/get-started).

src/content/docs/queues/configuration/configure-queues.mdx

@@ -9,11 +9,11 @@ head:
 
 ---
 
-import { WranglerConfig } from "~/components";
+import { WranglerConfig, Type } from "~/components";
 
 Cloudflare Queues can be configured using [Wrangler](/workers/wrangler/install-and-update/), the command-line interface for Cloudflare's Developer Platform, which includes [Workers](/workers/), [R2](/r2/), and other developer products.
 
-Each Worker has a `wrangler.toml / wrangler.json` file that specifies environment variables, triggers, and resources, such as a Queue. To enable Worker-to-resource communication, you must set up a [binding](/workers/runtime-apis/bindings/) in your Worker project's Wrangler file.
+Producer and Consumer Workers each have a `wrangler.toml / wrangler.json` file that specifies environment variables, triggers, and resources, such as a Queue. To enable Worker-to-resource communication, you must set up a [binding](/workers/runtime-apis/bindings/) in your Worker project's Wrangler file.
 
 Use the options below to configure your queue.
 
@@ -25,7 +25,24 @@ Below are options for Queues, refer to the Wrangler documentation for a full ref
 
 :::
 
-## Producer
+## Queue configuration
+The following Queue level settings can be configured using Wrangler:
+
+```sh
+$ npx run wrangler queues update --delivery-delay-secs 60 --message-retention-period-secs 3000
+```
+
+* `--delivery-delay-secs` <Type text="number" /> <Type text="optional" />
+	* How long a published message is delayed for, before it is delivered to consumers.
+	* Must be between 0 and 43200 (12 hrs).
+	* Defaults to 0.
+
+* `--message-retention-period-secs`  <Type text="number" /> <Type text="optional" />
+	* How long messages are retained on the Queue.
+	* Defaults to 345600 (4 days).
+	* Must be between 60 and 1209600 (14 days)
+
+## Producer worker configuration
 
 A producer is a [Cloudflare Worker](/workers/) that writes to one or more queues. A producer can accept messages over HTTP, asynchronously write messages when handling requests, and/or write to a queue from within a [Durable Object](/durable-objects/). Any Worker can write to a queue.
 
@@ -43,19 +60,17 @@ To produce to a queue, set up a binding in your Wrangler file. These options sho
 
 
 
-* <code>queue</code> string
+* <code>queue</code> <Type text="string" />
 
   * The name of the Queue.
 
-* <code>binding</code> string
+* <code>binding</code> <Type text="string" />
 
   * The name of the binding, which is a JavaScript variable.
 
 
 
-## Consumer
-
-## Workers
+## Consumers
 
 To consume messages from one or more queues, set up a binding in your Wrangler file. These options should be used when a Worker wants to receive messages from a queue.
 
@@ -78,32 +93,32 @@ Refer to [Limits](/queues/platform/limits) to review the maximum values for each
 
 
 
-* <code>queue</code> string
+* <code>queue</code> <Type text="string" />
 
   * The name of the Queue.
 
-* <code>max\_batch\_size</code> number optional
+* <code>max\_batch\_size</code> <Type text="number" /> <Type text="optional" />
 
   * The maximum number of messages allowed in each batch.
   * Defaults to `10` messages.
 
-* <code>max\_batch\_timeout</code> number optional
+* <code>max\_batch\_timeout</code> <Type text="number" /> <Type text="optional" />
 
   * The maximum number of seconds to wait until a batch is full.
   * Defaults to `5` seconds.
 
-* <code>max\_retries</code> number optional
+* <code>max\_retries</code> <Type text="number" /> <Type text="optional" />
 
   * The maximum number of retries for a message, if it fails or [`retryAll()`](/queues/configuration/javascript-apis/#messagebatch) is invoked.
   * Defaults to `3` retries.
 
-* <code>dead\_letter\_queue</code> string optional
+* <code>dead\_letter\_queue</code> <Type text="string" /> <Type text="optional" />
 
   * The name of another Queue to send a message if it fails processing at least `max_retries` times.
   * If a `dead_letter_queue` is not defined, messages that repeatedly fail processing will eventually be discarded.
   * If there is no Queue with the specified name, it will be created automatically.
 
-* <code>max\_concurrency</code> number optional
+* <code>max\_concurrency</code> <Type text="number" /> <Type text="optional" />
 
   * The maximum number of concurrent consumers allowed to run at once. Leaving this unset will mean that the number of invocations will scale to the [currently supported maximum](/queues/platform/limits/).
   * Refer to [Consumer concurrency](/queues/configuration/consumer-concurrency/) for more information on how consumers autoscale, particularly when messages are retried.