Provide extra info of the received signal for re-apply from reset, and others

[dhiaayachi]

Is your feature request related to a problem? Please describe. After reset, the signal reapply is great but sometimes I need to partially reapply to the new run. For example, some signals are from human that are important to keep. Some are not from human and it’s intended to drop so that workflow can behave differently. This is impossible to do today because there is no way to know if the signal is before or after reset point for reapply.

Additionally, it would be nice to provide info like the time of the signal. This is recorded in history event but not exposed in SDK.

Describe the solution you'd like It is possible to get this info from history— we have a reset event and then comes with a batch of history to reapply in that batch. So it would be nice if SDK can provide a flag to tell whether or not the signal is from reapply.

The new api may be something like :

type SignalInfo struct{
    FromReapply bool
    SendingTime time.Time
}

info, ok := channel.ReceiveAsyncWithInfo(&val)

Describe alternatives you've considered Another idea is to let server provide a feature to filter some signals when reapply — maybe based on signal names. But I feel like an SDK feature is better — more flexible and easier to implement

Additional context Slack thread with Temporal team(Maxim) https://temporalio.slack.com/archives/CTDTU3J4T/p1686762087116689?thread_ts=1686722741.716739&cid=CTDTU3J4T

[dhiaayachi]

Thank you for raising this feature request.

Currently, the Temporal SDK does not expose the information you requested on whether or not a signal came from a replay. However, here are a couple of workarounds you could use:

• Use a custom signal name. You could include a prefix in the signal name to distinguish signals sent during a replay.
• Use a MarkerRecorded event. You could have the workflow record a marker event to indicate that a signal came from a replay.

While these workarounds may be sufficient for now, we will consider your request to add a flag to the signal information in a future release.

We appreciate your feedback and look forward to your continued contributions!