misc: add cancel previous at e2e - #864
Merged
Merged
Conversation
timethink
pushed a commit
to timethink/sglang
that referenced
this pull request
Mar 9, 2025
efschu
pushed a commit
to efschu/htsglang
that referenced
this pull request
Aug 26, 2026
…ct#868's 15, and one keyword wide sgl-project#864. The question was whether the 16 standing failures are the same hermeticity form as the 15 that sgl-project#868 resolved. They are its MIRROR IMAGE, and the mirror is the direction that hurts: hermetic cards the desk gate shows sgl-project#868's 15 FAIL pass a red nobody can act on sgl-project#864's 16 SKIP FAIL a GREEN over a standing red Same class -- the invocation decides the verdict -- but sgl-project#868's announce themselves on every desk run, while these announce themselves nowhere anybody looks: the machine that can see them has cards, and the gate people read does not. CAUSE, proved without a card. hiradix_cache.py:266-278 calls all_reduce(tensor, op=op, group=group, async_op=True) unconditionally. The double at test_unified_radix_cache_unittest.py:2382 is fake(tensor, op=None, group=None). All 16 die with a TypeError inside mock's dispatch BEFORE their first assertion, so they are not evidence about SWA prefetch adoption in either direction. Checked the other half of the call too rather than assuming: the double returns None, and hicache_collective.py:190-196 documents None as a completed no-op -- so the drift is exactly one keyword wide and a one-line fix is the whole fix. TEST-ONLY. Zero live defects. sgl-project#783 gets nothing from them. Corrects the prior art it rests on: NOTE_861fg's "16 passed" hermetic is a numeric COINCIDENCE, not the same 16. Measured: -k tp_swa_prefetch under CVD="" gives 38 skipped / 0 passed / 0 failed (8+8 for want of a card, 11+11 non-SWA parametrisations; tally 38 == summary 38). They are inside the 1506 skips, not the 16 passes. sgl-project#862. mem_cache hermetic: 2 failed / 1774 passed / 1658 skipped, both tally axes OK (names 2 == summary 2; extracted 1658 == summary 1658). Both failures DEVICE-caused; REAL defects 0. The 1658 split by reason: HARDWARE 996 | DEPENDENCY 12 | CONFIG-not-darkness 645 | BY ACCIDENT 0 UNCLASSIFIED 5 So the darkness is BY DESIGN -- BY ACCIDENT is zero and the conftest mechanism explains itself in its own docstring. The ticket is still right for a finer reason: 1008 of those would run on a card and 645 would never run anywhere, and the summary line renders those identical facts. My own classifier was wrong first and the data said so: two buckets put 636 of 1658 in neither. Folding them into "dark" would have inflated the figure by 62 %. All 36 survivors were read individually and encoded; 5 remain unclassified and are reported as such rather than tuned away. Two more corrections to prior art: mem_cache DOES run directory-wide on CPU here (3396 collected, no abort), so the recorded collection-time abort does not reproduce on this tree -- reported, not bisected. And the escape behind it is real but at RUNTIME and two tests wide: rotation_executor.py:344 allocates with pin_memory=True, a device door that never calls get_device(), which is the one door the conftest guard patches. THE CHECK, in the CPU lane on purpose. New test_double_signature_drift_864.py (2 tests, 0.11 s, register_cpu_ci) parses the double and the production call sites and asserts the first can bind the second -- no device, no ranks, no import of a module that needs them. It also asserts production still passes async_op, so the guard reports a change instead of silently testing a call that no longer exists. Can-fail proven: re-introducing the drift turns it red with the exact diagnostic. Regression: mem_cache after the change is 2 failed / 1776 passed / 1658 skipped -- same failures, same skips, +2 from the new guard. NOT done and recorded: the 16 were never run WITH cards, so the fix is proved to remove the drift and not proved to make them pass. Every number here is a CVD="" number, verified on the process; nvidia-smi compute-apps showed only the other runner's serving ranks throughout. (cherry picked from commit a428907)
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
1 participant
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.
Thank you for your contribution, we really appreciate it. The following instructions will help improve your pull request and make it easier to receive feedback. If there are any items you don't understand, don't worry. Just submit the pull request and ask the maintainers for help.
Motivation
Please explain the motivation behind this PR and the goal you aim to achieve with it.
Modification
Briefly describe the changes made in this PR.
Checklist
pre-commit run --all-filesor other linting tools are used to fix potential lint issues.