wai-quantum: the branching test pins its reference run and forces the state vector's split paths #393

Merged

dcharlot merged 1 commit from wai/quantum-branching-threads-pinned into main 2026-10-21 12:11:03 -04:00

Conversation 0 Commits 1 Files changed 2 +35 -1

dcharlot commented 2026-10-21 07:56:20 -04:00

Owner

Copy link

quantum_noisy::tests::branching_runs_depend_on_neither_threads_nor_the_state_limit failed intermittently on the linux-arm64 runner on 2026-10-19: 5 runs in 20 that morning, in debug. It has not failed since. In the failing run, the reference run and a variant both moved, by a few parts in 10⁵ and differently, while the counts and histories were unchanged. So the test could not say which run was wrong.

Changes, all test-only:

• The reference run is pinned by a digest of its bits (estimates, counts, shots, histories), the same on every target: native, debug and release, and WASI. A failure of the pin says the reference itself moved; a failure of a comparison alone says a variant did.
• The split paths are forced again. From 16 qubits a run is one tree on the state vector's own threads, which since 0.6.8 split a pass only from 2¹⁸ amplitudes a thread. So the test's 16-qubit case no longer took the split paths it ran on that morning. It now forces them, with the state vector on 2 and 4 threads. This is skipped on wasm32, which has no threads.
• quantum_sv::with_forced_threads, a test-only helper.

Checked before this, on today's main; none found a defect:

• the whole library suite (716 tests) under AddressSanitizer: no error;
• the threaded tests under ThreadSanitizer, with the split paths forced: no race;
• the whole suite 8 times in the arm64 runner's own image: all passed;
• 240 forced-thread runs of the 16-qubit case in debug: all the same bits;
• the last 23 CI runs of the workflow on arm64: all passed.

This PR's test passes natively in release and in debug (83 s), and under WASI. The cause stays unproven; the test now catches it if it recurs, and says which run moved.

🤖 Generated with Claude Code

`quantum_noisy::tests::branching_runs_depend_on_neither_threads_nor_the_state_limit` failed intermittently on the linux-arm64 runner on 2026-10-19: 5 runs in 20 that morning, in debug. It has not failed since. In the failing run, the reference run and a variant both moved, by a few parts in 10⁵ and differently, while the counts and histories were unchanged. So the test could not say which run was wrong. **Changes, all test-only:** - **The reference run is pinned** by a digest of its bits (estimates, counts, shots, histories), the same on every target: native, debug and release, and WASI. A failure of the pin says the reference itself moved; a failure of a comparison alone says a variant did. - **The split paths are forced again.** From 16 qubits a run is one tree on the state vector's own threads, which since 0.6.8 split a pass only from 2¹⁸ amplitudes a thread. So the test's 16-qubit case no longer took the split paths it ran on that morning. It now forces them, with the state vector on 2 and 4 threads. This is skipped on wasm32, which has no threads. - `quantum_sv::with_forced_threads`, a test-only helper. **Checked before this, on today's main; none found a defect:** - the whole library suite (716 tests) under AddressSanitizer: no error; - the threaded tests under ThreadSanitizer, with the split paths forced: no race; - the whole suite 8 times in the arm64 runner's own image: all passed; - 240 forced-thread runs of the 16-qubit case in debug: all the same bits; - the last 23 CI runs of the workflow on arm64: all passed. **This PR's test** passes natively in release and in debug (83 s), and under WASI. The cause stays unproven; the test now catches it if it recurs, and says which run moved. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-10-21 07:56:20 -04:00

wai-quantum: the branching test pins its reference run and forces the state vector's split paths ... 6118b7e765

branching_runs_depend_on_neither_threads_nor_the_state_limit failed intermittently on
the linux-arm64 runner on 2026-10-19 (5 runs in 20 that morning, in debug), and has not
failed since. In the failing run the reference run and a variant both moved, by a few
parts in 10^5 and differently, with the counts and histories unchanged; so the test
could not say which run was wrong.

- The reference run is now pinned by a digest of its bits (estimates, counts, shots,
  histories), the same on every target. A failure of the pin says the reference
  itself moved; a failure of a comparison alone, a variant.
- From 16 qubits a run is one tree on the state vector's own threads, which since
  0.6.8 split a pass only from 2^18 amplitudes a thread. So this test's 16-qubit case
  no longer took the split paths it ran on that morning. It now forces them, with the
  state vector on 2 and 4 threads (not on wasm32, which has no threads).

What was checked before this, on today's main, found no defect:
- the whole library suite (716 tests) under AddressSanitizer: no error;
- the threaded tests under ThreadSanitizer, with the split paths forced: no race;
- the whole suite 8 times in the arm64 runner's own image: all passed;
- 240 forced-thread runs of the 16-qubit case in debug: all the same bits;
- the last 23 CI runs of the workflow on arm64: all passed.

The cause stays unproven. These tests now catch it if it recurs, and say which run moved.

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

dcharlot merged commit ccb772f46c into main 2026-10-21 12:11:03 -04:00

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

Merge pull request 'wai-quantum: the branching test pins its reference run and forces the state vector's split paths' (#393) from wai/quantum-branching-threads-pinned 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!393

No description provided.