Quantum Studio: a run on the job service whose answer is lost is sent again, safely #600

Merged

dcharlot merged 1 commit from wai/quantum-studio-service-retry into main 2026-11-03 15:10:55 -05:00

Conversation 0 Commits 1 Files changed 6 +142 -4

dcharlot commented 2026-11-03 06:27:11 -05:00

Owner

Copy link

The Studio's runs on the job service sent each job once, and gave up at the first lost answer, whether of the submission or of any poll. This is the browser's side of #596: the service's Idempotency-Key.

What changes

wai/quantum-studio/src/engine.js (ServiceEngine)

• The key: the Studio asks the service once whether it keeps keys (GET /v1's idempotency). To one that does, a run goes under an Idempotency-Key of its own, a random UUID.
• Sent again: where no answer comes back, the run is sent again under that key, twice at most, so a job the service took is answered rather than taken twice.
• To a service that keeps no keys, such as the one live today, the Studio sends no key and never sends a job twice. That service's CORS preflight does not allow the header, so sending a key would block the run in the browser. The Studio therefore works against today's service and starts sending keys once #596 is deployed.
• Polls: a poll whose answer is lost no longer ends the wait. Five lost in a row do.

The READMEs (in English and Chinese) and the CHANGELOG say so.

Tests

test/service.test.mjs, against a scripted fetch:

• a run whose submission's answer is lost is sent again under the same UUID and ends done;
• a service that keeps no keys is sent the job once, with no key header;
• a lost poll does not end the wait;
• the service is asked once whether it keeps keys;
• five lost polls in a row end the wait.

The studio workflow runs it on its three legs, beside the hardware test.

Checked

• node test/service.test.mjs: every check passes, here and in CI's image (catthehacker/ubuntu:act-22.04, Node 24).
• The views page rebuilt there with Rust 1.98.0 (wai-quantum-views/build.sh) is the committed bytes. engine.js is not one of its 49 sources, so build-views.mjs --check holds.
• The workflow parses. The public-name check is clean.

🤖 Generated with Claude Code

The Studio's runs on the job service sent each job once, and gave up at the first lost answer, whether of the submission or of any poll. This is the browser's side of #596: the service's `Idempotency-Key`. ## What changes `wai/quantum-studio/src/engine.js` (`ServiceEngine`) - **The key:** the Studio asks the service once whether it keeps keys (`GET /v1`'s `idempotency`). To one that does, a run goes under an `Idempotency-Key` of its own, a random UUID. - **Sent again:** where no answer comes back, the run is sent again under that key, twice at most, so a job the service took is answered rather than taken twice. - **To a service that keeps no keys,** such as the one live today, the Studio sends no key and never sends a job twice. That service's CORS preflight does not allow the header, so sending a key would block the run in the browser. The Studio therefore works against today's service and starts sending keys once #596 is deployed. - **Polls:** a poll whose answer is lost no longer ends the wait. Five lost in a row do. The READMEs (in English and Chinese) and the CHANGELOG say so. ## Tests `test/service.test.mjs`, against a scripted `fetch`: - a run whose submission's answer is lost is sent again under the same UUID and ends done; - a service that keeps no keys is sent the job once, with no key header; - a lost poll does not end the wait; - the service is asked once whether it keeps keys; - five lost polls in a row end the wait. The studio workflow runs it on its three legs, beside the hardware test. ## Checked - `node test/service.test.mjs`: every check passes, here and in CI's image (`catthehacker/ubuntu:act-22.04`, Node 24). - The views page rebuilt there with Rust 1.98.0 (`wai-quantum-views/build.sh`) is the committed bytes. `engine.js` is not one of its 49 sources, so `build-views.mjs --check` holds. - The workflow parses. The public-name check is clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-11-03 06:27:11 -05:00

Quantum Studio: a run on the job service whose answer is lost is sent again, safely ... 2e7a49cd7a

The Studio's runs on the job service sent each job once and gave up on
the first lost answer, of the submission or of any poll. A run now goes
under an Idempotency-Key of its own (a random UUID) to a service whose
description says it keeps keys, and is sent again under it, twice at
most, where no answer came back, so a job the service took is answered
rather than taken twice. A service that keeps no keys is sent no key,
which its CORS would refuse, and no job twice. A poll whose answer is
lost no longer ends the wait; five in a row do.

test/service.test.mjs holds each of these against a scripted fetch, and
the studio workflow runs it. The views page is unchanged: engine.js is
not among its sources, and rebuilt in CI's image it is the same bytes.

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

dcharlot merged commit e5c06365c2 into main 2026-11-03 15:10:55 -05:00

dcharlot referenced this pull request from a commit 2026-11-03 15:10:57 -05:00

Merge pull request 'Quantum Studio: a run on the job service whose answer is lost is sent again, safely' (#600) from wai/quantum-studio-service-retry into main

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!600

No description provided.