Dispatch object as the single dispatch contract #7
Description
Problem
Safe Actions improve dispatch race condition resistance, but cancellation control is currently internal and opaque.
Supporting developer supplied cancellation tokens alongside internal dispatch tracking adds complexity under the current engine architecture. Multiple token ownership models increase surface area for bugs.
Design Decision
The dispatch system will expose a single dispatch contract in the form of a Dispatch Object.
No separate async dispatch variants.
No implicit token ownership.
No hidden cancellation behavior.
Dispatch Object
The dispatch call returns a Dispatch Object containing:
- GUID identifying the dispatch instance
- Cancellation token associated with the dispatch
- Reserved space for future dispatch metadata
This object becomes the authoritative representation of a dispatch.
Token Strategy
- The dispatch tracker always assigns a token.
- The token is exposed via the Dispatch Object.
- Cancellation is performed through the token contained in the Dispatch Object.
- Developer supplied tokens are not injected into the pipeline.
Expected Behavior
- Every dispatch is uniquely identifiable.
- Cancellation is explicit and deterministic.
- Dispatch tracking is transparent and extensible.
- Engine complexity remains controlled.