Fix lost signal from Selector when Default path blocks #1682
Conversation
| @@ -551,6 +551,191 @@ func TestBlockingSelect(t *testing.T) { | |||
| require.EqualValues(t, expected, history) | |||
| } | |||
|
|
|||
| func TestSelectBlockingDefault(t *testing.T) { | |||
There was a problem hiding this comment.
We probably don't want the same test both here and in internal_workflow_testsuite_test.go right? Which file should hold this test?
There was a problem hiding this comment.
Actually maybe this is fine, one set tests w/ and w/o flags, and the other does default behavior
| readyBranch = func() { | ||
| // readyBranch is not executed when AddDefault is specified, | ||
| // setting the value here prevents the signal from being dropped | ||
| dropSignalFlag := getWorkflowEnvironment(ctx).GetFlag(SDKFlagBlockedSelectorSignalReceive) |
There was a problem hiding this comment.
What test did you add that test the true path here?
There was a problem hiding this comment.
TestSelectBlockingDefaultWithFlag tests the true scenario
There was a problem hiding this comment.
ah I see since the test environment always assumes the flag is true, hm I am not sure if we should assume that since the test environment would diverge from the real workflow environment, what do you think?
There was a problem hiding this comment.
I agree that the test environment shouldn't assume flags are true by default. That seems like a change that belongs in its own separate PR, I can create an issue for this
There was a problem hiding this comment.
To be clear I don't think SDK flags should be off by default in the test environment, I meant SDK flags used in the test environment should match what we enable when running a new workflow.
There was a problem hiding this comment.
Oops, I misunderstood, I agree.
Is there anywhere flags are set by default for a workflow? From looking at the code, it seems like TryUse are scattered around the code for different scenarios.
| require.EqualValues(t, expected, history) | ||
| } | ||
|
|
||
| func TestSelectBlockingDefaultWithFlag(t *testing.T) { |
There was a problem hiding this comment.
The reported bug was that blocking in the default case of a selector could cause signals to be lost, when I last looked at these tests we didn't seem to have any coverage for blocking in one selector case while a signal is received. Can we add tests to verify their is no bugs if a signal is received while blocking in another case of a selector, not just default?
What was changed
Fixed a lost signal, gated behind a new SdkFlag. Currently the flag is added, but never set anywhere, so existing behavior is unchanged. A separate PR will be added to enable the flag.
Why?
We shouldn't be losing a signal in our selector
Checklist
#1624
Added tests