Repository navigation
test(ep-cuda): list the cuFFT DFT sync, and check the allowlist's premise (fixes CUDA compile lane) - #2099
Merged
Conversation
…mise #2080 added an unconditional `stream().synchronize()` to `dft.rs::run` without adding it to the capture-sync contract's allowlist, so `CUDA compile (Linux x86_64)` has been red on main and on every branch cut from it since. The set difference is exactly one entry. The sync is legitimate. `DftKernel::capture_support` returns `CaptureSupport::unsupported`, and the barrier's own comment names it as one of the reasons: the step-scoped metadata prefix may be reused by the next dispatch, so the compute stream is drained before the synchronous default-stream upload. Listed with that justification. Listing it is the whole fix for the red lane. The second commit half is about what listing means. The allowlist carried the sentence "Every entry is a path whose capture_support is explicitly Unsupported" in a comment, where nothing checked it — so the list was also an unconditional escape hatch: one line silences the contract for a kernel that advertises `CaptureSupport::Supported`, and graph capture then breaks with the suite green. Silently, which is worse than the failure the contract exists to catch. `every_allowlisted_file_can_decline_capture` turns that sentence into an assertion. Its limit is stated in its own doc comment: it resolves `capture_support` per file, not per kernel, because the source scan is flat and has no `impl` awareness, so it is a lower bound. Falsified both directions, without a GPU — the contract test is a source scan and runs without `--features cuda`, which is how the CI failure was reproduced here byte-identically: - drop `dft.rs::run` from the list: the contract test FAILS with CI's exact left/right sets, so the entry is load-bearing; - make `dft.rs`'s `capture_support` return `Supported` while leaving the entry listed: `every_allowlisted_file_can_decline_capture` FAILS, so it is not vacuous. cargo test --locked -p onnx-runtime-ep-cuda --test capture_sync_contract: 2 passed, 0 failed. fmt clean. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This was referenced Aug 25, 2026
Owner
Author
|
Expect The lane this PR fixes is — Gaff |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2099 +/- ##
==========================================
+ Coverage 80.57% 80.60% +0.02%
==========================================
Files 412 428 +16
Lines 193684 209225 +15541
Branches 193684 209225 +15541
==========================================
+ Hits 156064 168642 +12578
- Misses 32136 34889 +2753
- Partials 5484 5694 +210
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
justinchuby
enabled auto-merge (squash)
August 25, 2026 10:30
This was referenced Aug 25, 2026
Closed
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
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.
CUDA compile (Linux x86_64)has been red onmainsince #2080, and every branch cut from it inherits the failure (seen on #2084: job 97720816964). The set difference is exactly one entry:The sync is legitimate; the omission was the list
#2080's cuFFT DFT kernel drains the compute stream before its metadata upload:and
DftKernel::capture_supportreturnsCaptureSupport::unsupported(…). So it qualifies under the contract's own rule — capture-unsupported paths are listed rather than guarded. Added with that justification.The rest of the PR: the allowlist's premise was never checked
Listing the entry is the whole fix for the red lane. But the allowlist carried its justification in a comment —
— and nothing checked it. That makes the list an unconditional escape hatch: a kernel advertising
CaptureSupport::Supportedwith an unguarded.synchronize()is silenced by one line, graph capture breaks, and the suite goes green. That is a worse outcome than the failure the contract exists to catch, because the contract is the only thing looking.every_allowlisted_file_can_decline_captureturns the sentence into an assertion. Its limit is stated in its own doc comment: it resolvescapture_supportper file, not per kernel, becausefunction_blocksis a flat scan with noimplawareness. It is a lower bound and says so.Falsified in both directions
The contract test is a pure source scan, so it reproduces without
--features cudaand without a GPU — that is how CI's failure was reproduced here byte-identically before any change."dft.rs::run"from the listdft.rs'scapture_supportreturnSupported, entry still listedevery_allowlisted_file_can_decline_captureFAILS — not vacuousThe second row is the one worth reading twice: under that mutation the pre-existing contract test still reports
ok. That is the silent escape hatch, demonstrated rather than asserted.Validation
The first is CI's exact command from the failing step. Test-only change; no production source is touched, so nothing here alters kernel behaviour.
Class
Catalogue #1817: a claim carried in prose where a check was available. The allowlist asserted its own entries were reviewed and had no way to be wrong about it.