Skip to content

Preserve reset request IDs in workflow history - #873

Open
Qian-Cheng-nju wants to merge 1 commit into
temporalio:mainfrom
Qian-Cheng-nju:fix/reset-request-history
Open

Qian-Cheng-nju wants to merge 1 commit into
temporalio:mainfrom
Qian-Cheng-nju:fix/reset-request-history

Conversation

@Qian-Cheng-nju

@Qian-Cheng-nju Qian-Cheng-nju commented Oct 1, 2026 •

Copy link
Copy Markdown

What changed?

Add reset_request_id to WorkflowTaskFailedEventAttributes for events with cause RESET_WORKFLOW, and regenerate the OpenAPI schemas. The field identifies the public reset request that created new_run_id. Internal resets leave it empty.

Why?

Reset request deduplication must survive history-based replication and mutable-state reconstruction. A request ID stored only in mutable state is lost under legacy event-based cross-cluster replication, so a retry after failover can create another reset run. Keeping the ID in the existing reset event lets the server rebuild its deduplication index without changing the workflow-start request ID used by callbacks.

Breaking changes

None at the wire level: this adds an optional proto3 string field. Older history has an empty value. Older servers do not gain the new deduplication behavior until upgraded.

Server PR

temporalio/temporal#12042

Validation

buf lint, buf breaking against main, buf build, API lint, OpenAPI generation and path-conflict check. The companion server changes pass local reset/rebuild and callback regressions, plus failover tests with transition history enabled and disabled, using locally generated Go bindings.

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.

1 participant