Quantum jobs on a provider outlive what sent them: the record, the command line, the desktop app and the Studio #590

Merged

dcharlot merged 5 commits from wai/quantum-provider-jobs-2 into main 2026-11-03 00:42:50 -05:00

Conversation 0 Commits 5 Files changed 36 +2393 -123

2026-11-02

Transaction Science

wai-quantum views: the page rebuilt for the Studio's new hardware words, in the image CI rebuilds it in ...

The views page carries the Studio's locales, so the words for a job waiting
at a provider changed its script. Rebuilt with wai/wai-quantum-views/build.sh
in catthehacker/ubuntu:act-22.04 with Rust 1.98.0 on x86_64, as the views
workflow rebuilds it: build-views.mjs --check passes. The engine inside it is
rebuilt too, from the engine as it is now; it had not been rebuilt since
cc08f85a0, and the 0.8.0 release and the registry, refusal and spd changes
since then changed its bytes, not its size.

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

8c296c402f

• View at this point in history

2026-11-02 22:19:02 -05:00

Transaction Science

wai-quantum-desktop release: the cask it writes passes brew style ...

The 0.1.1 cask had three findings in the tap: no blank line between each disk
image's sha256 and its url, and no depends_on :macos. The writer now puts both
in, and manifests_test.py checks them. Written from the 0.1.1 release's own
assets, the cask has no finding, and the Scoop manifest and latest.json are
byte for byte the ones published. (A minimum version is not given: the Intel
build states macOS 10.13, below what Homebrew supports, so brew style calls
it redundant.)

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

d41ee743d6

• View at this point in history

2026-11-02 22:19:02 -05:00

Transaction Science

Quantum Studio: a job on your own hardware outlives the window ...

A run on one of the person's providers waited inside the desktop app for up
to two hours, holding the Studio, and then cancelled the job, giving up its
place in a device's queue. The app now writes the job down before it sends
it, with the command line's records of jobs on a provider (#581), and asks
after it by its id.

- wai-quantum-desktop: run_on_provider answers within ten seconds, done or
  still running with its id; provider_job asks after a job once or cancels
  it; provider_jobs lists the jobs sent, asking no provider.
- Quantum Studio: while a job waits, Cancel cancels it at the provider and
  "Wait in the background" leaves it there and frees the Studio. A job left
  waiting, from this window or an earlier one, is followed while the app is
  open, and its result goes to the history when it finishes. Your jobs lists
  every job sent. A check that fails during the wait does not end it.
- The tests: the app's queued job answered by its id, sealed with the app's
  key, the same answer after, and cancelled only when asked; the page's
  wait, cancel, cancel-after-finish, failed check, background and reopened
  window. The studio workflow names the new app test on every leg.

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

2257b320fc

• View at this point in history

2026-11-02 22:19:02 -05:00

Transaction Science

wai-quantum-qpu.yml: the library has 46 tests, and the record's promises are named ...

The library's pinned count goes from 34 to 46, for the twelve tests the provider
job record adds. Five of them are named so CI fails if any stops running: a
recorded job outlives what sent it, running out of patience does not cancel it,
nothing is sent that was not recorded, a job that may have been sent is never
sent again, and a handle reaches no file but a record's.

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

065d464a8f

• View at this point in history

2026-11-02 22:18:51 -05:00

Transaction Science

wai-quantum-qpu and wai-quantum-cli: a job on a provider outlives what sent it ...

A run on a person's provider waited in its process, and a job that had not
finished in two hours was cancelled at the provider, losing its place in the
queue. If the process stopped first, the job went on and its id was gone, so its
counts could not be read. A device's queue can take days.

A job is now written down before it is sent, with everything sealing it will
need, and the provider's id as soon as the provider gives one. Nothing that
cannot be recorded is sent. Any process can come back to the record, and its
counts are read against the program that was sent, whatever the device's
calibration has become. Running out of patience leaves the job where it is. A
request that did not complete may have reached the provider, so it is never sent
again: that could be a second bill.

The command line gains run --no-wait and providers jobs, collect and cancel. The
local MCP server's run_on_provider answers within a call, and gains
get_provider_job, cancel_provider_job and list_provider_jobs.

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

5307518b27

• View at this point in history

2026-11-02 22:18:51 -05:00