@@ -16,7 +16,7 @@ implementations for [Cloudflare Workers]:
1616 - [ ` WorkersMessageQueue ` ]
1717
1818~~~~ typescript
19- import type { Federation } from " @fedify/fedify" ;
19+ import { createFederation , type Message } from " @fedify/fedify" ;
2020import { WorkersKvStore , WorkersMessageQueue } from " @fedify/cfworkers" ;
2121
2222export default {
@@ -26,22 +26,25 @@ export default {
2626 queue: new WorkersMessageQueue (env .QUEUE_BINDING ),
2727 // ... other options
2828 });
29-
30- return federation .handle (request , { contextData: env });
29+
30+ return federation .fetch (request , { contextData: env });
3131 },
32-
32+
3333 async queue(batch , env , ctx ) {
3434 const federation = createFederation ({
3535 kv: new WorkersKvStore (env .KV_BINDING ),
3636 queue: new WorkersMessageQueue (env .QUEUE_BINDING ),
3737 // ... other options
3838 });
39-
39+
4040 for (const message of batch .messages ) {
41- await federation .processQueuedTask (message .body );
41+ await federation .processQueuedTask (
42+ env ,
43+ message .body as unknown as Message ,
44+ );
4245 }
4346 }
44- } satisfies ExportedHandler <{
47+ } satisfies ExportedHandler <{
4548 KV_BINDING: KVNamespace <string >;
4649 QUEUE_BINDING: Queue ;
4750}>;
@@ -101,6 +104,14 @@ management.
101104> process the messages. The ` queue() ` method is the only way to consume
102105> messages from the queue in Cloudflare Workers.
103106
107+ > [ !NOTE]
108+ > If you use ` orderingKey ` when enqueueing messages, construct
109+ > ` WorkersMessageQueue ` with an ` orderingKv ` namespace and pass each raw queue
110+ > message through ` WorkersMessageQueue.processMessage() ` before calling
111+ > ` Federation.processQueuedTask() ` . This acquires and releases the best-effort
112+ > ordering lock for that key. You can also customize the lock behavior with
113+ > the ` orderingKeyPrefix ` and ` orderingLockTtl ` options.
114+
104115[ Cloudflare Queues ] : https://developers.cloudflare.com/queues/
105116
106117
0 commit comments