Skip to content

Hold the base workflow lock while forking reset history - #12008

Draft
taylan-oai wants to merge 1 commit into
temporalio:mainfrom
taylan-oai:dev/taylan/fence-history-branch-deletion
Draft

taylan-oai wants to merge 1 commit into
temporalio:mainfrom
taylan-oai:dev/taylan/fence-history-branch-deletion

Conversation

@taylan-oai

Copy link
Copy Markdown

Summary

Hold the base workflow lock until a replicated reset publishes its history branch, closing the gap where retention cleanup can run between lookup and fork.

Problem

The replicated-reset path loads the base workflow to select a history branch, then releases its workflow-cache lock before calling ForkHistoryBranch. Retention cleanup acquires that same lock and can delete the base history during the gap, before the reset branch exists as a reference.

Approach

Select and fork the branch within the existing base-workflow lease. Release the lease after the fork succeeds or fails, before rebuilding the reset workflow. Preserve the existing retry response for missing history and the storage layer's rewritten branch tokens.

Validation

  • Native changed-code lint passed.
  • A regression using the real workflow-context lock failed before the change: a competing lock acquisition succeeded during the fork. Both successful and failed fork cases pass after the change.
  • The regression verifies one release, fork-error propagation to the release function, and release before rebuilding.
  • The full NDC package passed; the resetter suite passed ten repetitions with the race detector.
  • Existing reset tests continue to cover rewritten base tokens and retry behavior.

Risks, rollout, and scope

The base workflow lock is held across one additional persistence call. Fork errors now reach the lease release function, which follows the existing cache error handling.

This closes the same-owner retention-cleanup gap in replicated resets. It does not add storage-level fencing across shard ownership changes or administrative force deletion. The regression establishes lock ordering; it does not reproduce a complete workflow with missing history or establish production frequency. No schema or API migration is required.

@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@yycptt
yycptt requested a review from simvlad September 11, 2026 21:19
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.

2 participants