[TRTLLM-15011][infra] Unwaive TestDeepSeekV4Flash::test_auto_dtype - #18000
[TRTLLM-15011][infra] Unwaive TestDeepSeekV4Flash::test_auto_dtype#18000lowsfer wants to merge 1 commit into
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)
💤 Files with no reviewable changes (1)
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review. WalkthroughThe pull request removes the skip waiver for ChangesDeepSeek test waiver
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This localized change re-enables an existing DeepSeekV4Flash test without changing production code or runtime behavior. No actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Superseded by #18095, which carries the actual fix for this bug family plus this waive removal. This PR's premise was that #17163 fixed the failure. That turned out to be wrong: the same root cause kept reproducing after #17163 merged (see https://nvbugs/6625710, filed 11 days later for the same signature). #18095 fixes it properly — an SSM snapshot evicted from the radix tree was detaching a block a live request still held — and removes this waive in the same change. |
|
Reopening — my earlier closing comment was wrong, and I want to correct the record. I closed this claiming the same root cause kept reproducing after #17163 merged. That conflated two distinct failure signatures:
The dates support the original premise here: 6561677 was filed Aug 4 and waived Aug 5, both before #17163 merged on Aug 6. It has produced no signal since, because it has been skipped ever since. 6625710, by contrast, was filed Aug 17 — after the merge — which is the evidence I mistakenly applied to this bug too. A stale/orphaned block also cannot produce the Per the bug's own instructions, CI here still needs the post-merge stage that test runs in: |
|
/bot run --disable-fail-fast |
|
PR_Github #68515 [ run ] triggered by Bot. Commit: |
|
PR_Github #68515 [ run ] completed with state
|
The test was waived for https://nvbugs/6561677, which failed teardown with "SlotAllocator::finishShrink: cannot finish shrink yet" because pages were still occupied when the pool group shrank to zero. That is the same root cause as https://nvbugs/6553427 (TestQwen3_5_35B_A3B::test_fp8[enable_block_reuse=True], "shrink can't be finished"): the KV cache manager tore down while requests were still open, so KvCache objects outlived the manager. PR NVIDIA#17163 drains in-flight requests before clearing the reuse state and guards clearReusableBlocks()/shutdown() against live caches. 6553427 was never waived and is already closed as fixed; this removes the remaining waive. Signed-off-by: Yao Yao <lowsfer@users.noreply.github.com>
97dc92d to
7e74dbb
Compare
|
/bot run --disable-fail-fast |
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
PR_Github #68758 [ run ] triggered by Bot. Commit: |
|
PR_Github #68758 [ run ] completed with state
|
Description
Removes the waive for
accuracy/test_llm_api_pytorch.py::TestDeepSeekV4Flash::test_auto_dtype(nvbugs/6561677, TRTLLM-15011).
The test aborted during LLM teardown with:
thrown from
SlotAllocator::finishShrink(storage/core.cpp), reached viaPoolGroupBase::destroy()→prepareForShrink(0)→finishShrink(). The shrink to zerofails because a slot is still occupied, i.e. a page was still alive at shutdown.
nvbugs/6553427
(
accuracy/test_llm_api_pytorch.py::TestQwen3_5_35B_A3B::test_fp8[enable_block_reuse=True],RuntimeError: shrink can't be finished) is the same root cause seen from the Python backend:the KV cache manager tears down while requests are still open, so
KvCacheobjects outlive theKVCacheManagerV2that owns their pages.Both are fixed by #17163, which drains in-flight requests before clearing the reuse state and
guards
clearReusableBlocks()/shutdown()so a call with live KV caches is rejected up frontrather than corrupting the pool.
Note that 6553427 was never waived (it was a pre-merge failure) and is already closed as
Bug - Fixed, so this PR only has one line to remove.Test Coverage
No new tests — this re-enables an existing one. The waived test ran in the post-merge stage
DGX_B200-4_GPUs-PyTorch-3, so CI must be run with that stage included:PR Checklist
Please review the following before submitting your PR:
PR description clearly explains what and why. If using CodeRabbit's summary, please make sure it makes sense.
PR Follows TRT-LLM CODING GUIDELINES to the best of your knowledge.
Test cases are provided for new code paths (see test instructions)
If PR introduces API changes, an appropriate PR label is added - either
api-compatibleorapi-breaking. Forapi-breaking, includeBREAKINGin the PR title.Any new dependencies have been scanned for license and vulnerabilities
CODEOWNERS updated if ownership changes
Documentation updated as needed
Update tava architecture diagram if there is a significant design change in PR.
The reviewers assigned automatically/manually are appropriate for the PR.
Please check this after reviewing the above items as appropriate for this PR.
GitHub Bot Help
To see a list of available CI bot commands, please comment
/bot help.🤖 Generated with Claude Code
Dev Engineer Review
accuracy/test_llm_api_pytorch.py::TestDeepSeekV4Flash::test_auto_dtypefromtests/integration/test_lists/waives.txt.#17163.DGX_B200-4_GPUs-PyTorch-3post-merge stage.QA Engineer Review
tests/integration/test_lists/waives.txt.accuracy/test_llm_api_pytorch.py::TestDeepSeekV4Flash::test_auto_dtype.test-db/orqa/files were modified.