Hi team,
We have a situation where a workflow was terminated before completion, with pending requests that had not been fulfilled.
Here's a representative snippet for how we resume the workflow from a custom JSON-based checkpointManager:
var resumedRun = await InProcessExecution.ResumeStreamAsync(workflow, checkpointInfo, checkpointManager, runId).ConfigureAwait(false);
The workflow resumes without any exceptions, but when we listen to the event stream we do not see the pending requests re-emitted:
Here's a sample of how we listen for events on the resumed run:
await foreach (WorkflowEvent evt in run.WatchStreamAsync().WithCancellation(cancellationToken)) {
...
}

^ The expected behaviour would be for the workflow to re-emit the pending requests.
Now, the foreach enumeration never executes. I can see in the runContext internal object that there are pending requests that should have been re-emitted:
I am also seeing that when I query the status of the workflow after resuming, it is set to RunStatus.NotStarted.
Based on my analysis, it looks like the pending requests are sent to an EventSink and then consumed via an observer when the runLoop begins in the StreamingRun and these events might be being lost before we attach an observer (which happens post restore).
Could I get some help understanding what might be the problem here, and if it is indeed a bug in the framework?
Hi team,
We have a situation where a workflow was terminated before completion, with pending requests that had not been fulfilled.
Here's a representative snippet for how we resume the workflow from a custom JSON-based checkpointManager:
The workflow resumes without any exceptions, but when we listen to the event stream we do not see the pending requests re-emitted:
Here's a sample of how we listen for events on the resumed run:
Now, the foreach enumeration never executes. I can see in the
runContextinternal object that there are pending requests that should have been re-emitted:I am also seeing that when I query the status of the workflow after resuming, it is set to
RunStatus.NotStarted.Based on my analysis, it looks like the pending requests are sent to an EventSink and then consumed via an observer when the runLoop begins in the StreamingRun and these events might be being lost before we attach an observer (which happens post restore).
Could I get some help understanding what might be the problem here, and if it is indeed a bug in the framework?