Skip to content

Consolidate event history docs and modernize Continue as New encyclopedia #3573

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Jun 12, 2025

Conversation

drewhoskins-temporal
Copy link
Contributor

@drewhoskins-temporal drewhoskins-temporal commented May 8, 2025

What does this PR do?

  • Removes duplicate explanations of event history limits.
  • Removes extraneous other documentation that is better addressed in other places.
  • Adds advice about versioning long-running workflows.
  • Modernizes continue-as-new overview to harmonize with the new per-SDK docs.
  • Tweaks python continue-as-new docs to give better advice.

Notes to reviewers

Test plan

yarn start
http://localhost:3000/workflow-execution/continue-as-new
Click on things
http://localhost:3000/workflow-execution/event#event-history-limits
Click on things

- [How to Continue-As-New using the Python SDK](/develop/python/continue-as-new)
- [How to Continue-As-New using the TypeScript SDK](/develop/typescript/continue-as-new)
- [How to Continue-As-New using the .NET SDK](/develop/dotnet/continue-as-new)
- [Determine when to Continue-As-New using the Go SDK](/develop/go/continue-as-new#when)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note: Other than python, these #when links don't exist yet, so they will link to the top of those pages until we finish those docs.

Copy link
Contributor

@dandavison dandavison left a comment

Choose a reason for hiding this comment

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

Nice improvement. Made a few suggestions.

Pass your latest relevant state into Continue-As-New.
This checkpoints it and passes it to a new Execution in the [Execution Chain](/workflow-execution#workflow-execution-chain).
This state is passed in through your Workflow's parameters.
The parameters are typically optional and left unset by the original caller of the Workflow.
Copy link
Contributor

@dandavison dandavison May 18, 2025

Choose a reason for hiding this comment

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

I'd probably get rid of "This checkpoints it" because as a reader that would make me think that Temporal had a thing called "checkpointing" that I didn't know about.

I'm also tempted to add a sentence saying something like

The end result is that you've created a new workflow with a fresh history that picks up where your last one left off.

All values passed to a Workflow Execution through parameters or returned through a result value are recorded into the Event History.
The Temporal Service stores the full Event History of a Workflow Execution for the duration of a Namespace's retention period.
A Workflow Execution that periodically executes many Activities has the potential of hitting the size limit.
You can repeat Continue-As-New as often as needed, which means that your Workflow can run in perpetuity.
Copy link
Contributor

Choose a reason for hiding this comment

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

Channeling the docs team I wonder if "can run forever" will be more widely understood without losing much in accuracy.


In the case of [Temporal Cron Jobs](/cron-job), Continue-As-New is actually used internally for the same effect.
To help prevent versioning problems for long-running Workflows, you may also want to Continue-as-New after a certain amount of time has elapsed. This will make sure every Workflow began on a recent version of your source code.
Copy link
Contributor

Choose a reason for hiding this comment

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

Not a versioning expert but this sounds a bit vague to me. After how much time? How do I know that a versioning error won't occur if the CAN is not issued at a precise point w.r.t. workflow code deploys?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Heh, we're working on a better answer here--Trampolining. So yeah, we don't have a satisfying answer ATM. Some users have used signals.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This really is the most practical advice for now, since very few users have chosen to use signals. My goal in this doc is to limit it to a few versions rather than one version.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wordsmithed.


To prevent _runaway_ Workflow Executions, you can use the Workflow Execution Timeout, the Workflow Run Timeout, or both.
A Workflow Execution Timeout can be used to limit the duration of Workflow Execution Chain, and a Workflow Run Timeout can be used to limit the duration an individual Workflow Execution (Run).
However, Workflow Executions intended to run indefinitely should be written with some care as they can run into [Event History limits](#event-history-limits).
Copy link
Contributor

@dandavison dandavison May 18, 2025

Choose a reason for hiding this comment

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

Could make this a bit more concrete:

Suggested change
However, Workflow Executions intended to run indefinitely should be written with some care as they can run into [Event History limits](#event-history-limits).
However, if your Workflow will perform many actions, or will receive many messages, then you should use Continue-As-New to avoid hitting [Event History limits](#event-history-limits) and performance degradation.

Copy link
Contributor

@brianmacdonald-temporal brianmacdonald-temporal left a comment

Choose a reason for hiding this comment

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

Looking good! I did some wordsmithing, but no major surgery.


The Continue-As-New feature enables developers to complete the current Workflow Execution and start a new one atomically.
## When is it right to Continue-As-New? {#when}
Copy link
Contributor

Choose a reason for hiding this comment

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

How about "When should you use Continue-As-New?" Seems more to-the-point, but I could be missing something.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wanted it to be clear that the question was at what point in the execution to continue as new rather than whether to use it. And "when should you" is fairly ambiguous.


The new Workflow Execution has the same Workflow Id, but a different Run Id, and has its own Event History.
To prevent scalability problems, periodically check Continue As New Suggested in your Workflow.\
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
To prevent scalability problems, periodically check Continue As New Suggested in your Workflow.\
To prevent scalability problems, periodically check Continue As New Suggested in your Workflow.

Where would the user see the "Continue As New Suggested" message? I'm trying to describe this something like "periodically check for the Continue As New Suggested message in the CLI" or however it works.


The new Workflow Execution has the same Workflow Id, but a different Run Id, and has its own Event History.
To prevent scalability problems, periodically check Continue As New Suggested in your Workflow.\
Temporal will tell your Workflow when it's approaching performance or scalability problems.
Copy link
Contributor

Choose a reason for hiding this comment

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

I suggest swapping lines 48 and 49. Tell the reader about this cool thing Temporal does, then tell them what to look for specifically.


In the case of [Temporal Cron Jobs](/cron-job), Continue-As-New is actually used internally for the same effect.
To prevent long-running Workflows from running on stale versions of code, you may also want to Continue-as-New periodically. This makes sure you're running only a couple of versions, which avoids some backwards compatibility problems.
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we define "periodically," or at least give some kind of guidelines? Weekly, monthly, every X number of executions?

Copy link
Contributor Author

@drewhoskins-temporal drewhoskins-temporal May 21, 2025

Choose a reason for hiding this comment

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

There's no concrete time frame because it depends on how frequently they deploy, which varies widely. Clarified.

You can use the [Continue-As-New](/workflow-execution/continue-as-new) feature to close the current Workflow Execution and create a new Workflow Execution in a single atomic operation.
The Workflow Execution spawned from Continue-As-New has the same Workflow Id, a new Run Id, and a fresh Event History and is passed all the appropriate parameters.
For example, it may be reasonable to use Continue-As-New once per day for a long-running Workflow Execution that is generating a large Event History.
For these reasons, it can be a good idea to [Continue-As-New](/workflow-execution/continue-as-new) periodically.
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment as above; if we could elaborate on "periodically," that might help user confidence.

@brianmacdonald-temporal brianmacdonald-temporal merged commit 74e6612 into main Jun 12, 2025
6 checks passed
@brianmacdonald-temporal brianmacdonald-temporal deleted the drewhoskins_CaN_2 branch June 12, 2025 22:52
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