Open to adding a PR? I’m about to step out as it’s the weekend

• Signal: Signal for the workflow itself to pause / resume / restart / stop; currently there's no way in a workflow to observe any signal natively, my prototype implementation involves using KV to write and read signals between each steps; still a hassle, and terminated workflow has no way to clear KV flags, so a cron job or expiring KV flags are needed.
• Long running task: It looks like the workflow has maximum steps limitation, along with the tendency to store all the results in the status, which is good for finite states; but for long, non-end state (unless interrupted) workflow, it might hit the limitation of max steps or max storage eventually since there's no way of clearing or discarding old results.
• Events: There's no way for a workflow to natively send events to other processes or back to the client, like SSE or Websocket. The workaround would be to implement would be using Queue or call upon a DO to monitor the results. (which kind of defeats the purpose of workflow).

Signals:

• First proposal: Allow the WorkflowEvent<T>WorkflowEvent<T> to change; the workflow would accept the original WorkflowEvent as some of sort constructor (so it could be accessed via this.initEventthis.initEvent etc; then the arguments in the

  run

  run

  indicates a modified arguments that the workflow can compare to; a change of value can indicate a signal
• Second proposal: Alternatively, allow WorkflowEvent<T>WorkflowEvent<T> to have signalsignal property, this property has special value that could be checked and changed unlike

  payload

  payload

  indicating the original value; the signalsignal property can have built-in signals like shouldStopshouldStop to indicate a built-in option for the workflow to be informed that it should gracefully transition into a stop or cancelled state with proper clean up.

• First proposal: Allow a previous state results to be discarded or overwritten if the same steps repeat itself (indicating a loop), this should be an opt-in behaviour and WorkflowStepConfigWorkflowStepConfig can accept a option to overrideResultoverrideResult; this may be harder to implement then the second porposal.
• Second proposal: Allow discard of staled state results, only preserve the newest 256 results and any older results are discarded. This would transfer the responsibility to preserve old data to new results to the user end; it's easier to be implemented, and requires minimal breaking change, where first proposal can be implementated later.

Uncaught SyntaxError: The requested module 'cloudflare:workers' does not provide an export named 'WorkflowStep'