temporalio
Provide extra info of the received signal for re-apply from reset, and others
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
I understand this generically, but if you have different signals that need to behave differently (e.g. some from human and some not), might it be best to provide that info in the signal argument?
I am a bit scared of encouraging people to write the workflow to do different things based on whether it was reset. Having said that, we have the unsafe/discouraged-for-use workflow.IsReplaying(ctx) bool. So maybe we can have a similar workflow.IsReplayingBeforeResetPoint(ctx) bool.
It’s actually for the signals after the reset point which are considered as “reapply”. The one before reset point shouldn’t be treated differently in workflow code.
There is no way for workflow to know by argument.
So is
!workflow.IsReplayingBeforeResetPoint(ctx)enough to know that?
No , it’s different than that…maybe I’ll make up a history as an example later.
The signals that I need to process differently are going to be re-processed again after reset, without any replay at all.
This requires a server-side change. The service must mark reapplied signals to distinguish them from the newly received signals.
