You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Signals received before the first workflow task are effectively not available to code running in the first workflow task. Notably, this happens when using start-with-signal.
This happens because since #261 events within the first workflow task are handled in the following order:
Markers for versions and side effects
Start workflow execution. This is always the first history entry in every workflow run. This causes workflow code to start executing.
Signals
Although 'start workflow execution' starts workflow code which can register a signal handler, no signals are invoked against those handlers until after the workflow code deschedules, such as when encountering a sleep or waiting for an activity to complete.
For example, consider the following code:
classReproWorkflow < Temporal::Workflowdefexecutereceived=nilworkflow.on_signaldo |signal,input|
received=inputendifreceived.present?'got signal'else'no signal'endend# Start this with a signalTemporal.start_workflow(ReproWorkflow,{signal_name: 'foo',signal_input: 'bar'})
The workflow started here will always return 'no signal' because received will not be updated until after the workflow function has already returned.
This problem does not exist outside of the first workflow task because the signal handler can simply be registered earlier in the workflow. It's not possible to pre-register a signal handler before execution.
Workarounds include:
Adding code that deschedules the workflow between signal handler registration and reading any of its effects, such as sleeping for 1 second before checking the value of received above
Accepting that signals will be delivered later in a workflow's execution than expected
Neither of these are great solutions, but they do limit the severity of this bug.
The text was updated successfully, but these errors were encountered:
Signals received before the first workflow task are effectively not available to code running in the first workflow task. Notably, this happens when using start-with-signal.
This happens because since #261 events within the first workflow task are handled in the following order:
Although 'start workflow execution' starts workflow code which can register a signal handler, no signals are invoked against those handlers until after the workflow code deschedules, such as when encountering a sleep or waiting for an activity to complete.
For example, consider the following code:
The workflow started here will always return
'no signal'
becausereceived
will not be updated until after the workflow function has already returned.This problem does not exist outside of the first workflow task because the signal handler can simply be registered earlier in the workflow. It's not possible to pre-register a signal handler before execution.
Workarounds include:
received
aboveNeither of these are great solutions, but they do limit the severity of this bug.
The text was updated successfully, but these errors were encountered: