ResetWorkflowExecution returns "workflow not found" when targets an older run

[jiechenz]

Expected Behavior

Resetting a workflow by an explicit runId should operate on that run.

If the workflow has no current execution — e.g. its current run was deleted while older runs still exist — there is no current run to terminate, so reset should create the new run from the base run and make it the current execution.

Actual Behavior

Reset always resolves the current execution first. When the current_executions record is missing, reset returns "workflow not found" regardless of the runId provided — even though the older run named by runId still exists.

Steps to Reproduce the Problem

1. Create a workflow wf and start run A and then run B
2. Terminate and delete run B
3. temporal workflow reset -w wf -r runA

Specifications

• Version: 1.31.1
• Platform: OS

[NasitSony]

I traced the reset path: with an explicit runID,
getWorkflowLeaseImpl → getWorkflowLease(runID) is called
directly (consistency_checker.go:246), which appears to
bypass current_executions lookup at this layer.

This suggests the 'workflow not found' error originates
either in:

1. GetOrCreateChasmExecution → persistence layer
   (possibly checks current_executions when loading), or
2. A different code path I haven't found yet

Could someone with more context on the cache/persistence
loading path point me toward where current_executions is
checked during GetOrCreateChasmExecution? Happy to continue
investigating with that pointer."

[NasitSony]

Found the exact location. In service/history/api/resetworkflow/api.go
(~line 85), after the base run (baseRunID) loads successfully via
baseWorkflowLease, the code unconditionally calls:

GetCurrentWorkflowRunID(ctx, namespaceID, workflowID, ...)

This looks up the current_executions table. When that record is
missing (e.g. the current run was deleted), this call fails and
the error is returned immediately — discarding the fact that the
base run (run A) was already loaded successfully just above.

I traced the lease/cache layer (consistency_checker.go, cache.go)
and confirmed that loading run A by explicit runID does NOT depend
on current_executions — it loads directly via persistence. So the
"workflow not found" doesn't come from the base run lookup, it
comes from this current-execution lookup that happens afterward.

A possible fix direction: when GetCurrentWorkflowRunID fails to
find a current execution, treat the base run itself as the
"current" run for the purposes of this reset (since reset's job
here is partly to establish a new current execution anyway).
Curious if there's a reason this should remain a hard failure,
or if that fallback is the right approach.

References:

• service/history/api/resetworkflow/api.go:84-86