Skip to main content

Task changes are published as events after they commit

Every change to a task, its comments or its links is published on one task event emitter once the change is committed, carrying the actor and the task before and after. The run manager subscribes to these events, for example stopping a run when a task is reassigned or passing a new comment into a running conversation, rather than being called from each place a task can change.

Considered Options​

  • Calling the run manager from each mutation: rejected; every new way of changing a task would have to remember it, and the task services would depend on agent runs.
  • Hooks that can veto a change before it happens: not built; nothing needs to block a change yet, and listeners that could fail a mutation would make every subscriber part of every write.

Consequences​

  • Listeners cannot undo or block a change, and a failing listener never fails the change that triggered it; its error is reported separately.
  • Listeners are called synchronously but asynchronous work is not awaited, so slow subscribers do not slow down the API.
  • Events are in-process: a subscriber in another process, or one that must survive a restart, needs a durable mechanism this does not provide.