[https://nvbugs/6435642][fix] avoid isinstance(MpiPoolSession) crash under session-reuse test infra - #16438
[https://nvbugs/6435642][fix] avoid isinstance(MpiPoolSession) crash under session-reuse test infra#16438MrGeva wants to merge 1 commit into
Conversation
…under session-reuse test infra _start_executor_workers() added isinstance(self.mpi_session, MpiPoolSession) to gate registering worker process identities with the new WorkerProcessMonitor. tests/test_common/session_reuse.py (an existing, default-on pytest speedup for bare LLM(...) tests) monkeypatches this module's MpiPoolSession attribute to a pool-reuse factory *function* so it can intercept `MpiPoolSession(n_workers=...)` construction calls. Under that patch, isinstance(x, MpiPoolSession) raises "isinstance() arg 2 must be a type, a tuple of types, or a union" because a function isn't a valid isinstance() type argument, crashing every MPI-mode LLM/executor test. Re-import MpiPoolSession from its origin module (tensorrt_llm.llmapi.mpi_session) at the check site instead of relying on this module's (intentionally monkeypatchable) module-level name, which the test-reuse pool-creation factory at self.mpi_session = MpiPoolSession(...) still needs to keep using. Signed-off-by: Eran Geva <19514940+MrGeva@users.noreply.github.com>
|
/bot run |
📝 WalkthroughWalkthrough
ChangesMPI pool session initialization
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
PR_Github #59472 [ run ] triggered by Bot. Commit: |
|
PR_Github #59472 [ run ] completed with state
|
|
/bot run |
|
PR_Github #59506 [ run ] triggered by Bot. Commit: |
|
PR_Github #59506 [ run ] completed with state
|
|
FYI #16444 has similar fix, plus verifying and unwaiving the previously failing tests. |
|
closing this PR in favor of #16444 |
Description
_start_executor_workers()intensorrt_llm/executor/proxy.py(added by #16338, merged 2026-07-14) does:tests/test_common/session_reuse.py— an existing, default-on pytest speedup for bareLLM(...)tests that reuses MPI worker pools across tests — monkeypatches this module'sMpiPoolSessionattribute to a pool-reusefactoryfunction, so it can interceptMpiPoolSession(n_workers=...)construction calls atself.mpi_session = MpiPoolSession(n_workers=model_world_size)(line 130).Under that patch,
isinstance(x, MpiPoolSession)raises:because a function isn't a valid
isinstance()type argument — crashing every MPI-modeLLM/executor test run undertests/unittest/(session-reuse is wired in globally viapytest.ini's-p test_common.session_reuse_hooks), not anything specific to one test file.Fix
Re-import
MpiPoolSessionfrom its origin module (tensorrt_llm.llmapi.mpi_session) at the check site, instead of relying on this module's module-level name — which must stay monkeypatchable for the pool-reuse factory to keep intercepting the construction call at line 130. The origin module's ownMpiPoolSessionattribute is never patched (onlytensorrt_llm.executor.proxyandtensorrt_llm.llmapi.llm's references are), so this always resolves to the real class.Test Coverage
Verified locally on 2×B200:
tests/unittest/auto_deploy/multigpu/smoke/test_ad_build_small_multi.py(the test that surfaced the bareTypeErrorin CI) — both cases pass, including the reused-pool path (2nd invocation is ~4x faster, confirming reuse still works).tests/unittest/auto_deploy/multigpu/custom_ops/test_ad_dist_strategies.py::test_allreduce_strategies[AUTO/TWOSHOT]— pass.tests/unittest/llmapi/test_mpi_session.py,tests/unittest/executor/test_proxy_fast_death.py,tests/unittest/executor/test_base_worker.py— 28/28 pass, no regressions on the non-reuse path.So this is a classic cross-PR integration bug: #16338's author added a new isinstance check without being aware that #15777 (merged the day before, unrelated area) had already made MpiPoolSession a name that test infrastructure legitimately monkeypatches. Neither PR is
wrong in isolation — the interaction between them is what broke, and it wouldn't have been caught by either PR's own tests since neither one's test suite exercises the other's code path in a way that surfaces the conflict.
Summary by CodeRabbit