From c381fb3da2ed323488023dc36507da614bcc4fae Mon Sep 17 00:00:00 2001 From: Dan Davison Date: Fri, 23 Jan 2026 15:01:09 -0500 Subject: [PATCH 1/3] Clarify message idempotency section --- .../workflow-message-passing/handling-messages.mdx | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/docs/encyclopedia/workflow-message-passing/handling-messages.mdx b/docs/encyclopedia/workflow-message-passing/handling-messages.mdx index 5987ce4675..e33fd3f57b 100644 --- a/docs/encyclopedia/workflow-message-passing/handling-messages.mdx +++ b/docs/encyclopedia/workflow-message-passing/handling-messages.mdx @@ -109,19 +109,17 @@ If you don’t need to ensure that your handlers complete, you may specify your See the links below for how to ensure handlers are finished in your SDK. -#### Ensuring your messages are processed exactly once {#exactly-once-message-processing} +#### Message IDs and handling Continue-As-New {#exactly-once-message-processing} -Many developers want their message handlers to run exactly once--to be idempotent--in cases where the same Signal or Update is delivered twice or sent by two different call sites. Temporal deduplicates messages for you on the server, but there is one important case when you need to think about this yourself when authoring a Workflow, and one when sending Signals and Updates. +Every message has one or more unique identifiers. Updates have an Update ID. It is set automatically to a UUID, but you can set it yourself. The Update ID is accessible to the Update handlers in your Workflow code. -When your workflow Continues-As-New, you should handle deduplication yourself in your message handler. This is because Temporal's built-in deduplication doesn't work across [Continue-As-New](/workflow-execution/continue-as-new) boundaries, meaning you would risk processing messages twice for such Workflows if you don't check for duplicate messages yourself. +In addition, both Signals and Updates have a request ID, which is set automatically in client calls. The same request ID is used in retries of the same call. It is not accessible to the message handlers in your Workflow code. -To deduplicate in your message handler, you can use an idempotency key. +Usually, you'll want your message handlers to run exactly once--to be idempotent--in cases where the same Signal or Update is delivered twice or sent by two different call sites. Temporal handles this for you on the server, by deduplicating according to the above identifiers. -Clients can provide an idempotency key. This can be important because Temporal's SDKs provide a randomized key by default, which means Temporal only deduplicates retries from the same call. For Updates, if you craft an Update ID, Temporal will deduplicate any calls that use that key. This is useful when you have two different callsites that may send the same Update, or when your client itself may get retried. For Signals, you can provide a key as part of your Signal arguments. +However, if you are using [Continue-As-New](/workflow-execution/continue-as-new), you must write your Workflow so that it uses an idempotency key received from the Signal or Update to check whether the Workflow has already handled the message. For Updates, you should use the Update ID as this idempotency key. For Signals, you should use a custom idempotency key that you send as part of your own signal inputs. -Inside your message handler, you can check your idempotency key--the Update ID or the one you provided to the Signal--to check whether the Workflow has already handled the update. - -See the links below for examples of solving this in your SDK. +See the links below for examples of doing this in your SDK. #### Authoring message handler patterns From 4d64af2920f72042df26872268631cc39e163a1b Mon Sep 17 00:00:00 2001 From: Dan Davison Date: Fri, 23 Jan 2026 15:15:09 -0500 Subject: [PATCH 2/3] v2 --- .../workflow-message-passing/handling-messages.mdx | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/docs/encyclopedia/workflow-message-passing/handling-messages.mdx b/docs/encyclopedia/workflow-message-passing/handling-messages.mdx index e33fd3f57b..cf88f2a2ae 100644 --- a/docs/encyclopedia/workflow-message-passing/handling-messages.mdx +++ b/docs/encyclopedia/workflow-message-passing/handling-messages.mdx @@ -111,15 +111,13 @@ See the links below for how to ensure handlers are finished in your SDK. #### Message IDs and handling Continue-As-New {#exactly-once-message-processing} -Every message has one or more unique identifiers. Updates have an Update ID. It is set automatically to a UUID, but you can set it yourself. The Update ID is accessible to the Update handlers in your Workflow code. +Usually, you'll want your message handlers to run exactly once--to be idempotent--in cases where the same Signal or Update is delivered twice or sent by two different call sites. Temporal handles this for you on the server, by deduplicating according to received message identifiers. -In addition, both Signals and Updates have a request ID, which is set automatically in client calls. The same request ID is used in retries of the same call. It is not accessible to the message handlers in your Workflow code. +However, if you are using [Continue-As-New](/workflow-execution/continue-as-new), you must write your Workflow so that it uses an idempotency key received from the Signal or Update to check whether the Workflow has already handled the message. For Updates, you should use the Update ID as this idempotency key. For Signals, you should use a custom idempotency key that you send as part of your own signal inputs. The Update ID is set automatically to a UUID, but you can set it yourself. -Usually, you'll want your message handlers to run exactly once--to be idempotent--in cases where the same Signal or Update is delivered twice or sent by two different call sites. Temporal handles this for you on the server, by deduplicating according to the above identifiers. +(In addition to these application-level identifiers, both Signals and Updates automatically use request IDs to deduplicate retried client calls. You do not need to do anything to enable this.) -However, if you are using [Continue-As-New](/workflow-execution/continue-as-new), you must write your Workflow so that it uses an idempotency key received from the Signal or Update to check whether the Workflow has already handled the message. For Updates, you should use the Update ID as this idempotency key. For Signals, you should use a custom idempotency key that you send as part of your own signal inputs. - -See the links below for examples of doing this in your SDK. +See the links below for examples of handling idempotency and Continue-As-New in your SDK. #### Authoring message handler patterns From 6e961f50b2fbaf7b4b1def3825cdc564a2eb3881 Mon Sep 17 00:00:00 2001 From: Dan Davison Date: Fri, 23 Jan 2026 15:22:15 -0500 Subject: [PATCH 3/3] v3 --- .../workflow-message-passing/handling-messages.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/encyclopedia/workflow-message-passing/handling-messages.mdx b/docs/encyclopedia/workflow-message-passing/handling-messages.mdx index cf88f2a2ae..a16ef54776 100644 --- a/docs/encyclopedia/workflow-message-passing/handling-messages.mdx +++ b/docs/encyclopedia/workflow-message-passing/handling-messages.mdx @@ -111,9 +111,9 @@ See the links below for how to ensure handlers are finished in your SDK. #### Message IDs and handling Continue-As-New {#exactly-once-message-processing} -Usually, you'll want your message handlers to run exactly once--to be idempotent--in cases where the same Signal or Update is delivered twice or sent by two different call sites. Temporal handles this for you on the server, by deduplicating according to received message identifiers. +Usually, you'll want your message handlers to run exactly once--to be idempotent--in cases where the same Signal or Update is delivered twice. For Updates, Temporal handles this for you on the server, by deduplicating according to the Update ID. For Signals, you should use a custom idempotency key that you send as part of your own signal inputs, implementing the deduplication in your Workflow code. The Update ID is set automatically to a UUID, but you can set it yourself. -However, if you are using [Continue-As-New](/workflow-execution/continue-as-new), you must write your Workflow so that it uses an idempotency key received from the Signal or Update to check whether the Workflow has already handled the message. For Updates, you should use the Update ID as this idempotency key. For Signals, you should use a custom idempotency key that you send as part of your own signal inputs. The Update ID is set automatically to a UUID, but you can set it yourself. +However, if you are using Updates with [Continue-As-New](/workflow-execution/continue-as-new) you should implement the deduplication in your Workflow code, since Update ID deduplication by the server is per Workflow run. (In addition to these application-level identifiers, both Signals and Updates automatically use request IDs to deduplicate retried client calls. You do not need to do anything to enable this.)