You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Idempotency ensures that multiple publishes of the same message cannot result in duplicate messages.
756
+
Idempotent publishing ensures that multiple attempts to publish the same message do not result in duplicate messages. This feature is essential when network issues may cause a client to reattempt message publication without knowing if the initial attempt succeeded.
757
757
758
+
<<<<<<< HEAD
758
759
It is possible that a client publishing a message using the REST interface may not receive acknowledgement of receipt from Ably, due to issues such as network failure outside of Ably's control. Clients will internally attempt to re-publish messages in these instances.
759
760
760
761
When idempotent publishing is enabled, the Ably SDK will internally assign a unique ID to each message which ensures that subsequent retry attempts cannot result in duplicate messages. Idempotent publishing is enabled by default in all latest Ably SDKs. It can be disabled by setting the @idempotentRestPublishing@ "@ClientOptions@":/api/rest-sdk#client-options to @false@.
761
762
762
763
Note that Ably can only detect duplicate messages within a 2-minute window after the original message, with the same ID, is published. If a message with the same ID is published after this 2-minute window, it will be treated as a new message.
763
764
764
765
You can also specify message IDs externally. The following is an example of how you might do this:
For versions 1.2 and later of the Ably library, idempotent publishing is enabled by default. This means the Ably SDK automatically assigns a unique ID to each message to prevent duplicates during retries. This functionality applies to both REST and realtime publishing.
770
+
For older versions (before 1.2), this feature was not enabled by default for publishing. However, it could be activated using @idempotentRestPublishing@ in "@ClientOptions@":/api/rest-sdk#client-optionsidempotentRestPublishing.
771
+
772
+
h4. Client ID idempotency
773
+
774
+
There are scenarios where specifying a client-supplied ID to achieve idempotency are necessary, such as:
775
+
776
+
* Ensuring idempotency when a publisher instance might be restarted, and continuous activity cannot be guaranteed.
777
+
* Integrating with an upstream system that uses its message IDs, ensuring idempotency across an entire message processing pipeline.
778
+
779
+
In these cases, you can manually specify the message ID for REST and realtime publishing.
780
+
781
+
The following example manually specifies a message ID:
782
+
783
+
```[realtime_javascript]
784
+
const realtime = new Ably.Realtime = '{{API_KEY}}';
If manually specifying message IDs, it is important to be aware of how messages are published when calling the "publish()":/api/rest-sdk/channels#publish method with an array of messages. See this "FAQ":https://faqs.ably.com/client-specified-message-id-restrictions-for-multiple-messages-published-atomically for further information.
904
+
```[rest_swift]
905
+
let rest = ARTRest(key: "{{API_KEY}}")
906
+
var channel = rest.channels.get("{{RANDOM_CHANNEL_NAME}}")
When specifying custom message IDs, particularly when attempting to "@publish()@":/api/rest-sdk/channels#publish multiple messages atomically with idempotency, ensure that the IDs adhere to the format restrictions. For more details on these restrictions, refer to the "FAQ":https://faqs.ably.com/client-specified-message-id-restrictions-for-multiple-messages-published-atomically.
806
941
807
942
h3(#publish-on-behalf). Use the REST interface to publish on behalf of a realtime connection
0 commit comments