Async job lifecycle: submit, poll, notify, cancel #144

New issue

Closed

opened 2026-08-12 11:11:22 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-12 11:11:22 +00:00

Member

Outcome

A summon can start work that takes minutes or hours, and the requester can find out how it went without holding a conversation open.

Why

Turns are request-scoped today, and Sirens Deep's trace p99 is already around 120s on ordinary conversational work. Real dev tasks are not a reply-latency shape at all. Without this, any long task either times out or blocks the transport.

Scope

Item 2 - async execution.

Submit returns a job id immediately rather than a completed answer.
Job state is pollable by id.
Completion notifies back through the originating transport, so a Discord requester is told in the place they asked.
Turn-scoped model budgets and tool-call budgets still apply per execution step. Async must not become a way to escape a bound.

Item 4 - cancellation.

A job in a cancellable state can be cancelled by its requester.
Cancellation is cooperative and defined: what stops immediately, what is allowed to finish, what is left behind.
A cancelled job reaches a terminal state and says why.

Acceptance

Submitting long work returns an id without holding the transport open.
Polling that id reports state truthfully at each stage.
Completion and failure both notify the origin.
A cancelled job stops, reaches a terminal state, and does not later report success.

Depends on

#143 - the job record and its state machine. Cancellation in particular is a state transition, so it needs the machine to exist first.

Next owner

Engineer.

## Outcome A summon can start work that takes minutes or hours, and the requester can find out how it went without holding a conversation open. ## Why Turns are request-scoped today, and Sirens Deep's trace p99 is already around 120s on ordinary conversational work. Real dev tasks are not a reply-latency shape at all. Without this, any long task either times out or blocks the transport. ## Scope **Item 2 - async execution.** * Submit returns a job id immediately rather than a completed answer. * Job state is pollable by id. * Completion notifies back through the originating transport, so a Discord requester is told in the place they asked. * Turn-scoped model budgets and tool-call budgets still apply per execution step. Async must not become a way to escape a bound. **Item 4 - cancellation.** * A job in a cancellable state can be cancelled by its requester. * Cancellation is cooperative and defined: what stops immediately, what is allowed to finish, what is left behind. * A cancelled job reaches a terminal state and says why. ## Acceptance * Submitting long work returns an id without holding the transport open. * Polling that id reports state truthfully at each stage. * Completion and failure both notify the origin. * A cancelled job stops, reaches a terminal state, and does not later report success. ## Depends on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/143 - the job record and its state machine. Cancellation in particular is a state transition, so it needs the machine to exist first. ## Next owner Engineer.

coilyco-ops referenced this issue

2026-08-12 11:12:55 +00:00

Job record: make a unit of work first-class, durable, and idempotent #143

coilyco-ops commented

2026-08-12 11:56:36 +00:00

Author

Member

Timing and store, from the batch decisions

Direction from Kai, 2026-08-12 session. Batch-wide decisions are recorded on the entry point, #143; this notes what reaches this unit.

Timing. The demo track owns the week to August 19. The batch starts August 20 and is the priority from then on. This unit begins once #143 lands, in parallel with #146 and the thread-binding half of #147.

The store is Postgres and it is already running, so #143 is not itself blocked on coilyco-bridge/deploy#391. That matters here because this unit's "polling that id reports state truthfully at each stage" and "a cancelled job reaches a terminal state and does not later report success" both depend on the state machine being genuinely durable rather than in-memory. It will be.

No scope change to this unit. Async submit, poll, notify, cancel, and the requirement that turn-scoped model and tool-call budgets still apply per execution step all stand as written.

One note on the notify path

Completion notifies back through the originating transport. For a Discord origin that will interact with #111, which is building a runtime-authored progress element with edits on tool boundaries and mandatory immediate resolution on every terminal state.

#111 is deferred past August 19 and this unit starts after it, so the likely order is progress element first, job completion notification second. Worth checking whether a completed job's notification should reuse that element or post separately — not a decision needed now, but a seam to look for rather than discover.

## Timing and store, from the batch decisions Direction from Kai, 2026-08-12 session. Batch-wide decisions are recorded on the entry point, #143; this notes what reaches this unit. **Timing.** The demo track owns the week to August 19. The batch starts August 20 and is the priority from then on. This unit begins once #143 lands, in parallel with #146 and the thread-binding half of #147. **The store is Postgres and it is already running**, so #143 is not itself blocked on `coilyco-bridge/deploy#391`. That matters here because this unit's "polling that id reports state truthfully at each stage" and "a cancelled job reaches a terminal state and does not later report success" both depend on the state machine being genuinely durable rather than in-memory. It will be. **No scope change to this unit.** Async submit, poll, notify, cancel, and the requirement that turn-scoped model and tool-call budgets still apply per execution step all stand as written. ## One note on the notify path Completion notifies back through the originating transport. For a Discord origin that will interact with #111, which is building a runtime-authored progress element with edits on tool boundaries and mandatory immediate resolution on every terminal state. #111 is deferred past August 19 and this unit starts after it, so the likely order is progress element first, job completion notification second. Worth checking whether a completed job's notification should reuse that element or post separately — not a decision needed now, but a seam to look for rather than discover.

coilyco-ops referenced this issue

2026-08-12 11:56:47 +00:00

Job-scoped telemetry and progress reporting #146

coilyco-ops referenced this issue

2026-08-12 11:56:57 +00:00

Structured commands and thread-to-job binding #147

coilyco-ops referenced this issue

2026-08-12 11:58:51 +00:00

Job record: make a unit of work first-class, durable, and idempotent #143

coilyco-ops referenced this issue from a commit

2026-08-12 12:00:44 +00:00

feat(jobs): make a unit of work first-class, durable, and idempotent