Re-enable stub-determinism CI check (issue #2203) - #2246
Merged
cqc-alec merged 3 commits intoSep 25, 2026
Merged
Conversation
The stub-generation CI check was neutered when nanobind 2.13.0 introduced non-deterministic stub output, turning the failure into a no-op with a comment referencing the issue. Investigation shows the non-determinism no longer occurs now that the repo is on nanobind 3.1.0: running ./stub_generation/regenerate_stubs repeatedly against the built extension produces byte-identical stubs every time, across multiple runs and PYTHONHASHSEED values. Restore the original fail-on-diff behaviour, and add a second regeneration pass that diffs against the first, so CI explicitly guards against a regression of the reported non-determinism.
The stub-generation CI check was disabled since issue Quantinuum#2203, so the committed stubs were never re-verified against the nanobind versions adopted afterwards (2.14.0, 2.15.0, 3.0.0, 3.0.1, 3.1.0). Regenerating against the currently pinned nanobind 3.1.0 shows circuit.pyi was stale: the args_wasm parameter of add_wasm/add_wasm_to_reg is rendered via a types.UnionType[...] expression that needs `import types`, which nanobind 2.13.0 (when the stub was last regenerated) did not require. This brings circuit.pyi back in sync with `./stub_generation/regenerate_stubs` so the restored CI check in the previous commit actually passes.
cqc-alec
approved these changes
Sep 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The stub-generation CI check (
Check type stubs are up-to-date and run mypyin
.github/workflows/build_and_test.yml) used to fail the build ifregenerating the
pytket.pyistubs produced a diff. When nanobind wasbumped from 2.12.0 to 2.13.0, stub output became non-deterministic, so the
fail-on-diff behaviour was disabled (commented out) and replaced with a
no-op, to keep CI green.
I investigated whether this is still an issue now that the repo is on
nanobind 3.1.0. Using the official
pytket==2.18.4wheel (built from thisexact commit) together with
nanobind==3.1.0, I ranstub_generation/regenerate_stubsrepeatedly — 10+ runs, across differentPYTHONHASHSEEDvalues and both Python 3.10 and 3.11 — and the generatedstubs were byte-identical every time. The non-determinism no longer
reproduces.
Since it's no longer reproducible, this PR restores the original
fail-on-diff check and adds a second regeneration pass that diffs against
the first, so CI explicitly re-verifies determinism (not just "matches the
committed stubs") on every run — guarding against a regression of the
original bug.
No source or stub files were changed; this is a CI-workflow-only fix.
Related issues
Fixes #2203
Checklist