Idiomatic way to run an action when a signal listen times out?

[maver1ck]

Hi @mrsimonemms, quick question on signal listens.

I've got the "wait for a signal, but not forever" shape from your approval-timeout example. metadata.timeout bounds the wait nicely, but instead of just failing on timeout I'd like to run a task (mark it overdue, send a reminder, etc.).

The obvious move — wrap the listen in a try and catch the timeout — is exactly what the example warns against, since it pushes the listen into a child workflow the signal never reaches. So I'm not sure where the "on timeout" branch is meant to go:

do:
  - waitForApproval:
      metadata:
        timeout: 30s
      listen:
        to:
          one:
            with:
              id: approve
              type: signal
  # if `approve` never arrives, I'd like to run a task here rather than fail

What's the intended pattern for this today, while keeping the listen top-level?

[mrsimonemms]

You’ve found a real limitation in the current implementation.

The intended shape should be to wrap the listen in a try and handle the timeout in catch. However, Zigflow currently executes each try block as a child workflow, which means a signal sent to the parent workflow cannot reach the listener inside it.

This is one of the problems being addressed by #525. That issue is primarily about the performance impact of compiling for and try blocks into child workflows, but executing try inline would also allow this pattern to work as expected.

So, today, there is not a good supported way to handle the timeout while keeping the listener on the parent workflow. Once #525 is implemented, the intended pattern should be an inline try/catch, ideally catching only the timeout error and then running your overdue or reminder tasks.

Thanks for raising this. This is important additional context for #525