cschleiden / go-workflows Goto Github PK

See https://github.com/temporalio/api/blob/c1f04d0856a3ba2995e92717607f83536b5a44f5/temporal/api/enums/v1/workflow.proto#L44-L52

Provide an API to access a PRNG that allows usage of "randomness". Perhaps record the seed of the PRNG and reuse this across, so that workflows remain deterministic despite using randomness.

• Support basic retries with max attempts
• Support exponential backoff with customization for activities
• Extract backoff behavior and reuse for sub-workflows

Depends on #58

SQL backends

Instead of duplicating events in the history and pending_events table, events should be stored in a single events table. history and pending_events should contain only references to the events.

Redis backend

• Separate payloads into a separate hash?

Implement by adding a cache to the workflow worker that keeps workflow executors in memory for some time. Extend the executor to execute new tasks on top of an in-memory workflow state.

Add support to backends to try to deliver subsequent workflow tasks to the same worker instance.

For mysql and sqlite backend:

1. Create multiple sub-workflows
2. Cancel parent workflow

Only one of the sub-workflows will be canceled

Similar to timer cancellation, cancel sub-workflows when the context used to create them is canceled.

• Implement and test
• Update "Guide" in Readme

Should check whether the usage is in a workflow.

We need to give workflow a chance to clean up

• Pending activities will run to completion; new activities will be skipped
• Cancel sub-workflows
• Allow to create a detached context to run any cleanup

A CLI or a UI to admin & debug workflows would be useful.

See if generics can make the Future and Channel handling easier. Especially avoiding the interface{} types in the Get calls for serialization/deserialization.

Extend the analyzer to also check for:

• usage of chan in workflows
• usage of WaitGroup in workflows
• usage of time.Now() and time.Sleep

• Workflow instances queue

• Lock workflow instances

• Activity queue

• Delayed (timer) events

• [ ] Sticky session behavior postponed for now

There are some flaky tests around sub-workflow cancellation propagation. We need to investigate and resolve those.

• Allow passing a span to CreateWorkflowInstance
• Persist the span with the instance
• Restore and inject into context for the workflow execution
• Wrap workflow execution
  • 🤔 Ignore replays?
• Restore and make available for activity execution
• Wrap activity execution
• Signals
• Cancellation

• Define interface with levels

Currently timer cancellation follows a model similar to DTFx: for timers only Scheduled and Fired events are recorded. Timer cancellation is solely handled in the workflow state. That means when a timer is cancelled, it must have been because inputs for the workflow (inputs, signals etc.) lead to the timer cancellation. A cancelled timer is recorded in the state and when at a later point it still fires (because the backend wasn't notified about the cancellation), the Fired event is recorded in the history, but since the timer is already cancelled, nothing is done in the Executor.

This works, but ideally we would give the backend a chance to clean up the timer. This is also going to be more in-line with "Sub-Workflow Cancellation", which DTFx doesn't support at all.

• Set expiration far in the future for all keys for pending workflow instances
• Set expiration somewhat in the future for all keys for completed workflow instances

Keys:

• history:<instance_id>
• pending-events:<instance_id>
• state:<instance_id>

Supports: #28

When root context is canceled, stop polling for new work, complete in-progress work, and then exit.

Have some kind of timeout.

Today the worker just panics. Instead a better error message should be shown.