Skip to content

Clarify message idempotency section#4144

Open
dandavison wants to merge 5 commits intomainfrom
message-idempotency
Open

Clarify message idempotency section#4144
dandavison wants to merge 5 commits intomainfrom
message-idempotency

Conversation

@dandavison
Copy link
Contributor

@dandavison dandavison commented Jan 23, 2026

What does this PR do?

Clarifies the section on idempotency keys and CAN. There were reports that for the following sentence

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.

it was not obvious that it referred to the situation when the workflow is using CAN.

@dandavison dandavison requested a review from a team as a code owner January 23, 2026 20:05
@vercel
Copy link

vercel bot commented Jan 23, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
temporal-documentation Ready Ready Preview, Comment Mar 5, 2026 7:43pm

Request Review

@github-actions
Copy link
Contributor

github-actions bot commented Jan 23, 2026

📖 Docs PR preview links

#### 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.
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd move the last sentence about UUID next to the Update sentence. The Signal sentence breaks the flow there in the middle.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be simpler to just ask people to check idempotency. And then explain the reasoning that it's necessary for signals and update plus CaN .
That way, if they add CaN later, they won't cause a bug. And I don't think there is much harm to a redundant check.

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}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that this is focused on CaN now. The part about the same Update/Signal coming in from different clients is now only implied. That might be fine.

@flippedcoder flippedcoder self-assigned this Jan 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants