Signal requestID dropped upon workflow reset

dhiaayachi commented 2 months ago

Expected Behavior

I am not sure if this is expected or not, but at least existing behavior looks weird to me

On workflow reset, signal got picked to the new run together with corresponding signal requestID so that dedup can still work.

Actual Behavior

After reset, signal event got picked but not signal request ID.

Steps to Reproduce the Problem

Change tctl code to include a requestID when sending signals
Start a workflow
Use the modified tctl to signal it several time.
Terminate the workflow started in 2
Run tctl admin desc command, signalRequestedIds field is shown.
Reset the workflow to first workflow task (any reset type will do I think, but I haven't verified)
Run tctl admin desc command for the new run, there's no signalRequestedIds field.

Specifications

Version: master
Platform:

dhiaayachi commented 1 month ago

Thanks for reporting this issue. We're missing some context to be able to find a solution.

Please clarify if you are using the Go SDK or another SDK.

dhiaayachi commented 1 month ago

Thank you for reporting this issue.

This behavior is expected as the signal requested IDs are not persisted as part of the workflow's event history and are only kept in memory while the workflow is running. This is because the signal request IDs are not required for the workflow's execution and are mainly used for deduplication purposes.

Currently, there is no direct workaround to preserve the signal request IDs across workflow resets, as it is not a feature of Temporal's current design.

You can find more information about Signals, Queries, and Updates in the Workflow message passing section of our documentation.

We appreciate your feedback and are always looking for ways to improve Temporal. Please let us know if you have any other questions.

dhiaayachi / temporal