Unhandled signal

[leowmjw]

For test case sending multiple same signal at the same time; it detects unhandled signal

			env.SignalWorkflow("signal-receive-with-timeout", &message)
			env.SignalWorkflow("signal-receive-with-timeout-clone", &message)
			env.SignalWorkflow("signal-receive-with-timeout", &message)
			env.SignalWorkflow("signal-receive-with-timeout", &message)

The newer SDK also have selector.HasPending but not sure if that is useful in this scenario

Maybe something like below:

	selector.AddFuture(
		timer,
		func(f workflow.Future) {
			if err := f.Get(ctx, nil); err != nil && temporal.IsCanceledError(err) {
				fmt.Println("WORKFLOW CANCELED!!!!!")
				isCancelled = true
			} else {
				fmt.Println("TIMED OUT!!!")
				hasTimedOut = true
			}
		},
	)
	selector.AddReceive(
		sigCh,
		func(c workflow.ReceiveChannel, more bool) {
                        // This handles multiple signals of same type
			for c.ReceiveAsync(valuePtr) {
				fmt.Println("MORE SIGNALS!!!")
			}
		},
	)

[MrSaints]

Thanks for filing the issue!

I'm not sure in what scenario we want to process the additional signals, and how we can offer this to customers using this library.

That said, when we used ReceiveWithTimeout in our own projects, we do have a use-case for draining the signal channel before using it to ensure we take the latest.

For example, if we were to run ReceiveWithTimeout in a loop:

1. Receive signal
2. Workflow continues progressing
3. While (2) is happening, more signals are still being received, and collected
4. When the loop comes back round, (1) is instantly fired

To avoid (4), we run something like:

for {
    hasData := sigCh.ReceiveAsync(nil)
    if !hasData {
        break
    }
}

res := channel.ReceiveWithTimeout(ctx, sigCh, &result, timeout)

If this is a common requirement, we can easily back this in.