fix(e2e): remove stale eagle VL waives - #1141
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review. 📝 SummarySummary
Architecture impact
HUMAN REVIEW REQUIRED — Confirm the name-resolution correction and trigger CI for the current PR head before merge. WalkthroughThe change removes two obsolete E2E waivers and adds validation that every remaining waiver references a declared E2E test case across supported platforms. ChangesE2E waiver validation
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change removes obsolete E2E waivers and adds validation that remaining waiver names map to declared test cases. No current merge-blocking risk remains. Suggested reviewers: 🚥 Pre-merge checks | ✅ 8 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (8 passed)
Full details: Description checkExplanation The description follows the repository template and provides complete background, exit criteria, implementation details, change classification, validation results, environment information, remaining gaps, notes, and risk rationale. Full details: Family Ownership BoundaryExplanation PASS. The pull request changes only the central waiver file and the central Full details: Shared Semantic NeutralityExplanation PASS. The diff changes only Full details: Benchmark Validation IntegrityExplanation PASS — The committed diff changes only Full details: Shared Change Blast RadiusExplanation The PR changes a shared E2E waiver validation surface, but it documents the required blast radius. The description identifies the model-agnostic need: stale names in the centralized waiver file become silently inert and may later match a case. Repository evidence shows that Comment |
|
@yifeif-nv This PR is ready for CI. Please trigger CI for the current head. |
f39ec4c to
5109fe5
Compare
|
Thanks for contribution @Moviw there is some minor issue with the name resolution. Please help to correct that and I'm happy to trigger the internal CI for you! Looking forward to your future contribution |
waives.txt skipped "eagle-embed-vl-1b-v2" and "eagle-rerank-vl-1b-v2" for a 404 HF repo. No manifest declares either name. The eagle_vlm manifests are nemotron-embed-vl-1b-v2 and nemotron-rerank-vl-1b-v2 (plus their tp4 variants), pointing at nvidia/llama-nemotron-embed-vl-1b-v2 and nvidia/llama-nemotron-rerank-vl-1b-v2, both listed Green in the support matrix. The repo is reachable and the names are gone, so the reason and the subjects are both stale. _load_waives matches purely by model name and skips anything it cannot parse, so these entries have been silently inert rather than failing. If either name were ever reused, the waive would spring back and skip a Green model with no one asking for it. Add a CPU guard so the next stale entry is reported instead of rotting: every waived name must resolve to a manifest declared through the E2E harness's own iter_manifest_paths(), across every platform prefix the file mentions. The guard reproduces exactly these two names before the deletion. Follows 19316ed, which removed the stale Qwen TorchTRT waive. Resolve waived names against the child E2E testcase namespace via get_case_names(), the harness canonical source, rather than top-level manifest names: the runtime matches a waive against case.name, and 50 of the 272 case names are not manifest names, so the earlier guard would have falsely reported those as inert. Signed-off-by: Moviw <xvzimo@gmail.com>
5109fe5 to
5399cbd
Compare
|
@yifeif-nv Thanks — you were right, and it turned out to be a real defect rather than wording. The runtime resolves waives against Fixed as suggested in Public CI is green (7/7) on the current head. Ready for the internal CI whenever you have a slot. |
Background
tests/e2e/waives.txtskipped two models for a 404 Hugging Face repo:No manifest declares either name. The
eagle_vlmmanifests arenemotron-embed-vl-1b-v2andnemotron-rerank-vl-1b-v2(plus their-tp4variants), pointing at
nvidia/llama-nemotron-embed-vl-1b-v2andnvidia/llama-nemotron-rerank-vl-1b-v2. Both are listed 🟢 Green inwebsite/data/model-support-matrix.md. The repo is reachable and the waivednames are gone, so both the subjects and the reason are stale.
_load_waivesmatches purely by model name and skips any line it cannotparse, so these entries have been silently inert rather than failing — which is
exactly why they rotted unnoticed. If either name were ever reused, the waive
would spring back and skip a Green model with no one asking for it.
Precedent:
19316ed9 fix(e2e): remove stale Qwen TorchTRT waive.No originating issue; found while surveying
eagle_vlmcoverage.Exit Criteria
tests/e2e/waives.txtcontains no entry naming a model with no declaredmanifest.
_load_waivesplatform-selection coverage is unchanged.Non-goals: no change to
_load_waivesitself, to the per-familywaives.txtfiles, or to any manifest.Implementation
Remove the two stale entries. Add
test_every_waive_names_a_declared_manifestto the existingtests/tools/test_e2e_waives.py: every waived name must resolve to a manifestdeclared through the E2E harness's own
iter_manifest_paths(), collectedacross every platform prefix the file mentions so platform-scoped waives are
also checked.
The guard reuses the harness loader rather than globbing, so it follows the
same indexed/flat/nested manifest layouts the harness supports.
Affected components:
tests/e2e/waives.txt,tests/tools/test_e2e_waives.py.No public API, ABI, bundle-format, or dependency change.
Change categories
Validation
Commands and Results
Test-first. With the guard added and
tests/e2e/waives.txtstill atupstream/main, it reproduces exactly the two stale names:After removing the two entries:
The two pre-existing tests in this file are unchanged; the diff on it is
purely additive (0 deleted lines).
Full CPU
tests/tools, on this branch and onupstream/main, using the samemarker set and the same deselect the workflow applies for filesystems without
reflink support:
The single extra pass is the new guard. No failures on either side.
The two public gates that run without a GPU:
Evidence for the staleness claim:
Consistency checks:
Unit evidence only. No inference, parity, performance, or qualification claim.
Hardware, Environment, and Revisions
e9f45793(upstream/main), branch rebased onto it.requirements/community-ci.txt, plus numpy, PyYAML, torch 2.5.1+cu121,safetensors, transformers, tensorrt 11.2.1.2 and cuda-python so the full
tests/toolsset collects.Not Run / Remaining Gaps
selection, since
_load_waivesnever matched it.Community CPU / Docsjob was not run locally; this change touchesnothing under
website/.tools.community_ci unit --scope all,which requires Docker; Docker on this host needs privileges the contributor
account does not have. The same test set was run directly instead, as
recorded above.
tests/e2e/waives.txtonly. The fiveper-family
waives.txtfiles are loaded by each family's ownrunner.pyand are currently header-only; extending the guard to them is model-owned
work and is left to those owners.
Notes For Future Readers
The silent-
continuebehavior in every waive loader is the root of this: awaive that stops matching stops doing anything, and nothing reports it. The
guard turns the next occurrence into a CPU failure instead of a slow rot.
Promoting the loader itself to reject unparseable lines would be a stronger
fix, but it changes
_load_waivesbehavior for all callers and belongs in aseparate change.
Risk level
Deletes two entries that provably matched nothing, and adds one test. No
production code touched.