Scope CustomShardingPropagator to test_dtensor tests via pytest fixture#367
Merged
Scope CustomShardingPropagator to test_dtensor tests via pytest fixture#367
Conversation
This was referenced Mar 17, 2026
meta-cla
bot
added
the
CLA Signed
tests/test_dtensor.py
Outdated
|
|
||
|
|
||
| @pytest.fixture(autouse=True, scope="module") | ||
| def _restore_propagator(): |
Contributor
There was a problem hiding this comment.
This is not being called?
The module-level `dispatcher.sharding_propagator = CustomShardingPropagator()` was leaking into other test files (e.g. test_api.py) when run in the same pytest process, causing `aten.copy_` failures because the custom propagator doesn't have rules for ops that the default DTensor propagator handles. test_dtensor.py's two test classes (ImplicitRegistrationTest, DimShardingTest) inherit from DTensorTestBase which uses MultiProcessTestCase -- each test spawns subprocesses that re-import the module. Those subprocesses don't run pytest fixtures, so they need the custom propagator installed at module level. We gate the module-level install on `multiprocessing.current_process().name` to only run in spawned workers, and use a module-scoped autouse pytest fixture to install/restore the propagator in the main process. Authored with Claude. stack-info: PR: #367, branch: xmfan/stack/32
xmfan
changed the title
xmfan
added a commit
that referenced
this pull request
Mar 17, 2026
* Scope CustomShardingPropagator to test_dtensor tests via pytest fixture The module-level `dispatcher.sharding_propagator = CustomShardingPropagator()` was leaking into other test files (e.g. test_api.py) when run in the same pytest process, causing `aten.copy_` failures because the custom propagator doesn't have rules for ops that the default DTensor propagator handles. test_dtensor.py's two test classes (ImplicitRegistrationTest, DimShardingTest) inherit from DTensorTestBase which uses MultiProcessTestCase -- each test spawns subprocesses that re-import the module. Those subprocesses don't run pytest fixtures, so they need the custom propagator installed at module level. We gate the module-level install on `multiprocessing.current_process().name` to only run in spawned workers, and use a module-scoped autouse pytest fixture to install/restore the propagator in the main process. Authored with Claude. stack-info: PR: #367, branch: xmfan/stack/32 * Add lazy Inductor compilation to graph_pp_runner Add _execute_graph() that lazily compiles graph modules with compile_fx_inner on first invocation. Controlled by an inductor kwarg threaded through all _run_* functions. GraphPPRunner accepts inductor=True and propagates it to all GraphPipelineStage instances, which the stage_* action functions read when calling _run_*. Authored with Claude. stack-info: PR: #360, branch: xmfan/stack/30
xmfan
added a commit
that referenced
this pull request
Mar 17, 2026
* Scope CustomShardingPropagator to test_dtensor tests via pytest fixture The module-level `dispatcher.sharding_propagator = CustomShardingPropagator()` was leaking into other test files (e.g. test_api.py) when run in the same pytest process, causing `aten.copy_` failures because the custom propagator doesn't have rules for ops that the default DTensor propagator handles. test_dtensor.py's two test classes (ImplicitRegistrationTest, DimShardingTest) inherit from DTensorTestBase which uses MultiProcessTestCase -- each test spawns subprocesses that re-import the module. Those subprocesses don't run pytest fixtures, so they need the custom propagator installed at module level. We gate the module-level install on `multiprocessing.current_process().name` to only run in spawned workers, and use a module-scoped autouse pytest fixture to install/restore the propagator in the main process. Authored with Claude. stack-info: PR: #367, branch: xmfan/stack/32 * Add lazy Inductor compilation to graph_pp_runner Add _execute_graph() that lazily compiles graph modules with compile_fx_inner on first invocation. Controlled by an inductor kwarg threaded through all _run_* functions. GraphPPRunner accepts inductor=True and propagates it to all GraphPipelineStage instances, which the stage_* action functions read when calling _run_*. Authored with Claude. stack-info: PR: #360, branch: xmfan/stack/30 * Add --inductor flag to example_ds3_pp with FORCE_BALANCED_ROUTING The DSv3 MoE implementation uses .tolist() and data-dependent grouped_mm offsets that Inductor cannot compile. Add FORCE_BALANCED_ROUTING to the model that makes token-per-expert counts uniform and uses balanced all-to-all splits, eliminating all data-dependent ops. The --inductor CLI flag enables both Inductor compilation and forced balanced routing together. Authored with Claude. stack-info: PR: #361, branch: xmfan/stack/31
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
3 participants
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.
Stacked PRs:
Scope CustomShardingPropagator to test_dtensor tests via setUp/tearDown
The module-level
dispatcher.sharding_propagator = CustomShardingPropagator()was leaking into other test files (e.g. test_api.py) when run in the same
process, causing
aten.copy_KeyError failures because the custom propagatordoesn't have rules for ops that the default DTensor propagator handles.
Replace the global mutation with a setUp/tearDown mixin that installs the
custom propagator before each test and restores the original afterwards.
Authored with Claude.