wai-quantum-service: a job the service was running when it stopped runs once more #613

Merged

dcharlot merged 1 commit from wai/quantum-service-rerun into main 2026-11-04 12:10:52 -05:00

Conversation 0 Commits 1 Files changed 16 +305 -64

dcharlot commented 2026-11-04 10:33:27 -05:00

Owner

Copy link

A job that was running when the job service stopped came back interrupted, with its request kept, and nothing ran it again unless its client sent it again. The engine is deterministic, so the same request runs to the same result. The service now runs such a job once more itself.

It is one commit on main, which now has the idempotency key (#607, which replaced #596). It was written on top of #596's commit and replayed onto main after #607 and #608 merged; the patch is unchanged.

What changes

wai-quantum-service

• On start: a job that was running is queued again, in its order, to run once more from its stored request. It is planned again under the service's limits, as a queued job is, and fails with the reason if it no longer fits. Its interruptions list each time the service stopped while it ran.
• Stopped again: if the service stops again while the job runs once more, the job comes back interrupted with the reason, and is not run a third time (RERUNS = 1). A job that stops the service whenever it runs therefore cannot run for ever.
• Receipts: a job run again is sealed as any job is, and its receipt verifies.
• Keys: a job run again still answers for its idempotency key (#607). One that ends interrupted frees its key, as before.
• Counts: GET /v1's restored counts the jobs run again (rerun), and so does the start-up log.
• Descriptions: the OpenAPI document gives interruptions. get_quantum_job's description says what a restart does.

wai-quantum: wai.quantum.job/1 lists interrupted among its statuses. The service has returned that status since its jobs were first kept across restarts, but the schema did not list it. The schema also gains the optional interruptions. Both are minor changes: one new value of a listed member and one optional member.

The tool snapshot and the agent docs are regenerated.

Tests

• The service's store: two jobs running when the service stopped are both queued again, each with one interruption and no start, error or result. One runs to its end, and its receipt verifies. The other is stopped again and comes back interrupted, with two interruptions and the reason, and is not queued again. Both read as the job schema says. Opened once more, it stays as it is.
• The existing restart tests:
  • The running job is now queued again, alongside the queued one, and both still count against their clients.
  • A key names a job that is run again, and is freed once the job ends interrupted.
• The service killed twice (tests/restart.rs):
  • After the first kill, the job it was running runs again, first in its order, with one interruption, while the job behind it waits.
  • Killed during that rerun, the job comes back interrupted with two interruptions and is not run a third time.
  • The job queued behind it then runs, and its receipt verifies.
  • restored counts each start.
• The engine's schema: a job queued again with its interruptions, and an interrupted job, each read as wai.quantum.job/1.

Checked

On the build host, on this commit as replayed onto main (e00d956f2):

• wai-quantum's schema tests;
• the service's tests, the restart test that kills it twice among them, and its clippy with -D warnings;
• the command line's tests, which hold the committed tool lists and agent docs to what the binary generates;
• check_schemas.py over every schema file, both tool lists and a release build's answers.

Before the replay, on the same patch: the command line's clippy, with and without default features. The public-name check is clean, and so are this description and the commit message.

🤖 Generated with Claude Code

A job that was running when the job service stopped came back `interrupted`, with its request kept, and nothing ran it again unless its client sent it again. The engine is deterministic, so the same request runs to the same result. The service now runs such a job once more itself. It is one commit on main, which now has the idempotency key (#607, which replaced #596). It was written on top of #596's commit and replayed onto main after #607 and #608 merged; the patch is unchanged. ## What changes **wai-quantum-service** - **On start:** a job that was running is queued again, in its order, to run once more from its stored request. It is planned again under the service's limits, as a queued job is, and fails with the reason if it no longer fits. Its `interruptions` list each time the service stopped while it ran. - **Stopped again:** if the service stops again while the job runs once more, the job comes back `interrupted` with the reason, and is not run a third time (`RERUNS` = 1). A job that stops the service whenever it runs therefore cannot run for ever. - **Receipts:** a job run again is sealed as any job is, and its receipt verifies. - **Keys:** a job run again still answers for its idempotency key (#607). One that ends `interrupted` frees its key, as before. - **Counts:** `GET /v1`'s `restored` counts the jobs run again (`rerun`), and so does the start-up log. - **Descriptions:** the OpenAPI document gives `interruptions`. `get_quantum_job`'s description says what a restart does. **wai-quantum:** `wai.quantum.job/1` lists `interrupted` among its statuses. The service has returned that status since its jobs were first kept across restarts, but the schema did not list it. The schema also gains the optional `interruptions`. Both are minor changes: one new value of a listed member and one optional member. The tool snapshot and the agent docs are regenerated. ## Tests - **The service's store:** two jobs running when the service stopped are both queued again, each with one interruption and no start, error or result. One runs to its end, and its receipt verifies. The other is stopped again and comes back interrupted, with two interruptions and the reason, and is not queued again. Both read as the job schema says. Opened once more, it stays as it is. - **The existing restart tests:** - The running job is now queued again, alongside the queued one, and both still count against their clients. - A key names a job that is run again, and is freed once the job ends interrupted. - **The service killed twice** (`tests/restart.rs`): - After the first kill, the job it was running runs again, first in its order, with one interruption, while the job behind it waits. - Killed during that rerun, the job comes back interrupted with two interruptions and is not run a third time. - The job queued behind it then runs, and its receipt verifies. - `restored` counts each start. - **The engine's schema:** a job queued again with its interruptions, and an interrupted job, each read as `wai.quantum.job/1`. ## Checked On the build host, on this commit as replayed onto main (e00d956f2): - wai-quantum's schema tests; - the service's tests, the restart test that kills it twice among them, and its clippy with `-D warnings`; - the command line's tests, which hold the committed tool lists and agent docs to what the binary generates; - `check_schemas.py` over every schema file, both tool lists and a release build's answers. Before the replay, on the same patch: the command line's clippy, with and without default features. The public-name check is clean, and so are this description and the commit message. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-11-04 10:33:27 -05:00

wai-quantum-service: a job the service was running when it stopped runs once more ... 1b07caf646

A job that was running when the service stopped came back interrupted,
its request kept, and nothing ran it again unless its client sent it
again. Since the engine gives the same result for the same request, the
service now runs it again itself: on start, a job that was running is
queued again in its order, to run once more from its stored request, and
its `interruptions` say when the service stopped. Stopped again while it
runs once more, it comes back interrupted with the reason and is not run
a third time (RERUNS = 1), so a job that stops the service whenever it
runs does not run for ever. GET /v1's `restored` counts the jobs run
again.

wai.quantum.job/1 now lists `interrupted` among its statuses, which the
service has returned since its jobs were kept across restarts, and the
optional `interruptions`.

Also: the store's pseudonym test held the hex of a keyed hash to not
containing "203", three digits of the address, which a random key gives
about once in 140 runs. It now holds it to hex, which cannot spell the
address.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit 7731c9c817 into main 2026-11-04 12:10:52 -05:00

dcharlot referenced this pull request from a commit 2026-11-04 12:10:53 -05:00

Merge pull request 'wai-quantum-service: a job the service was running when it stopped runs once more' (#613) from wai/quantum-service-rerun into main

dcharlot referenced this pull request 2026-11-04 12:11:30 -05:00

wai-quantum-service: the runs are MCP tasks, each task its job #615

dcharlot referenced this pull request 2026-11-04 15:47:49 -05:00

wai-quantum 0.8.1, wai-quantum-qpu 0.4.1, wai-quantum-cli 0.2.4, the job service 0.2.2 and the Python package 0.1.2 #619

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!613

No description provided.