From 09005714582ec7a29c6d47a80f9d29496b41127b Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 23:27:15 +0200 Subject: [PATCH 1/5] Do Webhooks support ordered messages? --- .../docs/platform/integrations/webhooks/index.mdx | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/pages/docs/platform/integrations/webhooks/index.mdx b/src/pages/docs/platform/integrations/webhooks/index.mdx index d0b7247b48..4b745f1124 100644 --- a/src/pages/docs/platform/integrations/webhooks/index.mdx +++ b/src/pages/docs/platform/integrations/webhooks/index.mdx @@ -92,7 +92,15 @@ The backoff delay follows the formula: `delay = delay * sqrt(2)` where the initi The back off for consecutively failing requests will increase until it reaches 60s. All subsequent retries for failed requests will then be made at 60s intervals until a request is successful. The queue of events is retain for 5 minutes. If an event cannot be delivered within that time then events are discarded to prevent the queue from growing indefinitely. -### Batched event payloads +## Message ordering + +Webhooks don't always preserve message order the same way Ably channels do. It depends on how you've set up your webhook. + +With batched webhooks, messages stay in order as long as they're from the same publisher on the same channel. If a batch fails and gets retried, newer messages get included but they'll still be in the right order. Messages from different regions might arrive in separate batches, but that's fine since ordering is per-publisher anyway. + +Single request webhooks can't guarantee order. Each message fires off its own HTTP request, and there's no telling which one arrives first. If your server supports HTTP/2 though, you get ordering back because requests get pipelined down one connection. + +One gotcha: if you're publishing via REST (not realtime), you lose ordering guarantees even with batching on. That's because REST uses a connection pool where requests can finish out of order. Given the various potential combinations of enveloped, batched, and message sources, it's helpful to understand what to expect in different scenarios. From 5efa65a12178b61256e48406875bde12eea409d6 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 23:33:21 +0200 Subject: [PATCH 2/5] Why are my Lambdas occasionally triggered more than once? --- src/pages/docs/platform/integrations/webhooks/lambda.mdx | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/pages/docs/platform/integrations/webhooks/lambda.mdx b/src/pages/docs/platform/integrations/webhooks/lambda.mdx index 0fe8827936..7c0e3db37a 100644 --- a/src/pages/docs/platform/integrations/webhooks/lambda.mdx +++ b/src/pages/docs/platform/integrations/webhooks/lambda.mdx @@ -105,3 +105,11 @@ Then ensure the checkbox for the policy is selected. 8. You don't need to add tags so click **Next: Review**. 9. Enter a suitable name for your role. 10. Click **Create Role**. + +## Lambda retry behavior + +Ably invokes Lambda functions asynchronously using the `event` invocation type. When a function returns an error, AWS Lambda automatically retries the execution up to two more times with delays between attempts (1 minute, then 2 minutes). + +This means your Lambda function might occasionally run multiple times for the same Ably event. Design your functions to handle this - either make them idempotent or check for duplicate processing. + +You can configure retry behavior in your AWS Lambda console under the function's asynchronous invocation settings. See the [AWS Lambda documentation](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) for details on adjusting retry settings. From 07a7f055006b19daefd333a3b630ed7f814b641f Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 23:49:46 +0200 Subject: [PATCH 3/5] Can I make changes to a queue after it has been created? --- src/pages/docs/platform/integrations/queues.mdx | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/pages/docs/platform/integrations/queues.mdx b/src/pages/docs/platform/integrations/queues.mdx index 2ca26a3f4d..dddb86f8db 100644 --- a/src/pages/docs/platform/integrations/queues.mdx +++ b/src/pages/docs/platform/integrations/queues.mdx @@ -78,6 +78,20 @@ The following steps explain how to provision an Ably Queue: A [Dead Letter Queue](#deadletter) is automatically created. It stores messages that fail to be processed, or expire. +### Modifying queues + +Queues can't be changed after creation - they're immutable. If you need different settings, you'll need to create a new queue and migrate. + +Here's how to switch to a new queue: + +1. Create a new queue with your desired settings +2. Update your consumers to subscribe to both the old and new queues +3. Change your queue rules to route messages to the new queue +4. Wait for the old queue to drain completely +5. Delete the old queue once empty + +This process ensures no message loss during the transition. + ### Configure a Queue rule After you provision a Queue, create one or more Queue rules to republish messages, presence events, or channel events from channels into that queue. From 5bd2fa4d15cfd43c2cb9354b57407e8cae816633 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 23:53:00 +0200 Subject: [PATCH 4/5] I upgraded but my queue still has the old message limits? --- src/pages/docs/platform/integrations/queues.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/pages/docs/platform/integrations/queues.mdx b/src/pages/docs/platform/integrations/queues.mdx index dddb86f8db..270f6c63b6 100644 --- a/src/pages/docs/platform/integrations/queues.mdx +++ b/src/pages/docs/platform/integrations/queues.mdx @@ -82,6 +82,8 @@ A [Dead Letter Queue](#deadletter) is automatically created. It stores messages Queues can't be changed after creation - they're immutable. If you need different settings, you'll need to create a new queue and migrate. +This includes limits like TTL and max length. Even if you upgrade your Ably account, existing queues keep the limits they were created with. You'll need to replace them to get the higher limits from your new plan. + Here's how to switch to a new queue: 1. Create a new queue with your desired settings From c93bc10c2cd3e6a23170733d069000392b23be22 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Tue, 30 Sep 2025 15:02:02 +0200 Subject: [PATCH 5/5] Tidy up commit --- src/pages/docs/platform/integrations/queues.mdx | 16 ++++++++-------- .../platform/integrations/webhooks/index.mdx | 8 ++++---- .../platform/integrations/webhooks/lambda.mdx | 5 ++--- 3 files changed, 14 insertions(+), 15 deletions(-) diff --git a/src/pages/docs/platform/integrations/queues.mdx b/src/pages/docs/platform/integrations/queues.mdx index 270f6c63b6..3a3414be72 100644 --- a/src/pages/docs/platform/integrations/queues.mdx +++ b/src/pages/docs/platform/integrations/queues.mdx @@ -80,17 +80,17 @@ A [Dead Letter Queue](#deadletter) is automatically created. It stores messages ### Modifying queues -Queues can't be changed after creation - they're immutable. If you need different settings, you'll need to create a new queue and migrate. +Queues cannot be modified after creation because they are immutable. Different settings require creating a new queue and migrating. -This includes limits like TTL and max length. Even if you upgrade your Ably account, existing queues keep the limits they were created with. You'll need to replace them to get the higher limits from your new plan. +This includes limits like TTL and max length. Even after [upgrading](/docs/account/billing-and-payments#upgrading) an Ably account, existing queues retain the limits they were created with. Replacement is required to get the higher limits from a new plan. -Here's how to switch to a new queue: +Steps to switch to a new queue: -1. Create a new queue with your desired settings -2. Update your consumers to subscribe to both the old and new queues -3. Change your queue rules to route messages to the new queue -4. Wait for the old queue to drain completely -5. Delete the old queue once empty +1. Create a new queue with the required settings. +2. Update consumers to subscribe to both the old and new queues. +3. Change queue rules to route messages to the new queue. +4. Wait for the old queue to drain completely. +5. Delete the old queue once empty. This process ensures no message loss during the transition. diff --git a/src/pages/docs/platform/integrations/webhooks/index.mdx b/src/pages/docs/platform/integrations/webhooks/index.mdx index 4b745f1124..78d6cd063f 100644 --- a/src/pages/docs/platform/integrations/webhooks/index.mdx +++ b/src/pages/docs/platform/integrations/webhooks/index.mdx @@ -94,13 +94,13 @@ The back off for consecutively failing requests will increase until it reaches 6 ## Message ordering -Webhooks don't always preserve message order the same way Ably channels do. It depends on how you've set up your webhook. +Webhooks do not always preserve message order the same way Ably channels do. This depends on the webhook configuration. -With batched webhooks, messages stay in order as long as they're from the same publisher on the same channel. If a batch fails and gets retried, newer messages get included but they'll still be in the right order. Messages from different regions might arrive in separate batches, but that's fine since ordering is per-publisher anyway. +Batched webhooks preserve message order when messages are from the same publisher on the same channel. If a batch fails and gets retried, newer messages are included while maintaining correct order. Messages from different regions might arrive in separate batches, maintaining per-publisher ordering. -Single request webhooks can't guarantee order. Each message fires off its own HTTP request, and there's no telling which one arrives first. If your server supports HTTP/2 though, you get ordering back because requests get pipelined down one connection. +Single request webhooks cannot guarantee order. Each message triggers its own HTTP request, and arrival order is not predictable. HTTP/2 server support can restore ordering through request pipelining over a single connection. -One gotcha: if you're publishing via REST (not realtime), you lose ordering guarantees even with batching on. That's because REST uses a connection pool where requests can finish out of order. +Publishing via REST (not realtime) removes ordering guarantees even with batching enabled, as REST uses a connection pool where requests can complete out of order. Given the various potential combinations of enveloped, batched, and message sources, it's helpful to understand what to expect in different scenarios. diff --git a/src/pages/docs/platform/integrations/webhooks/lambda.mdx b/src/pages/docs/platform/integrations/webhooks/lambda.mdx index 7c0e3db37a..877876c1ff 100644 --- a/src/pages/docs/platform/integrations/webhooks/lambda.mdx +++ b/src/pages/docs/platform/integrations/webhooks/lambda.mdx @@ -57,7 +57,6 @@ The following steps show you how to create a policy for an AWS Lambda. ```json -{ { "Version": "2012-10-17", "Statement": [ @@ -106,10 +105,10 @@ Then ensure the checkbox for the policy is selected. 9. Enter a suitable name for your role. 10. Click **Create Role**. -## Lambda retry behavior +## Lambda retry behavior Ably invokes Lambda functions asynchronously using the `event` invocation type. When a function returns an error, AWS Lambda automatically retries the execution up to two more times with delays between attempts (1 minute, then 2 minutes). -This means your Lambda function might occasionally run multiple times for the same Ably event. Design your functions to handle this - either make them idempotent or check for duplicate processing. +Lambda functions might run multiple times for the same Ably event. Design functions to handle this by making them idempotent or checking for duplicate processing. You can configure retry behavior in your AWS Lambda console under the function's asynchronous invocation settings. See the [AWS Lambda documentation](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) for details on adjusting retry settings.