viable/strict/1789540965: Update handler clearance logic (#196102)
PyTorch 仓库合并 PR #196102，修改 test_logging.py 的 handler 清理逻辑。原代码遍历 log_internal.log_registry.get_log_qnames() 收集 logger.handlers 并断言每个 logger 恰好有 2 个 handler；在 pytest 分片运行下，pytest 额外注入 4 个 NOTSET handler，导致断言失败（Expected 2 but got 6）。改动后只校验 PyTorch 自身管理的 handler 数量为 2，而非 logger 的 handler 总数。
Development
- First Reportviable/strict/1789540965: Update handler clearance logic (#196102)PyTorch Core
- Current Assessment对大型开源项目而言，测试在分片与不同 runner 下的可移植性是持续维护成本；此类修复通常不改变对外 API，但会影响下游依赖 nightly/分片 CI 的团队。可验证下一信号：该改动是否被 backport 到发布分支，以及分片 CI 失败率是否下降。Agent Pulse · analysis
PyTorch 合并 PR #196102，修复 test_logging.py 在 pytest 分片模式下失败的问题。原测试通过 log_internal.log_registry.get_log_qnames() 遍历所有 logger，断言每个 logger 的 handlers 数量为 2，理由是只应有 stream 与 file handler。但用 pytest 运行时，pytest 会额外注册 4 个 NOTSET handler，使总数变为 6，触发 AssertionError: Scalars are not equal! Expected 2 but got 6。修复方式是改为只统计 PyTorch 自己管理的 handler 数量为 2，不再断言 logger 的 handler 总数。审阅者包括 @bobrenjc93、@xuhancn、@ezyang。
这是测试隔离问题而非运行时缺陷：断言把「PyTorch 管理的 handler 数」与「logger 上的 handler 总数」混为一谈，任何外部框架（此处为 pytest）注入 handler 都会破坏该不变量。更稳健的做法是断言 PyTorch 注册的 handler 集合，或在 fixture 中隔离/恢复 logging 状态。可验证下一信号：后续 PR 是否引入 logging fixture 或按 handler 来源过滤，而非仅放宽计数。
对大型开源项目而言，测试在分片与不同 runner 下的可移植性是持续维护成本；此类修复通常不改变对外 API，但会影响下游依赖 nightly/分片 CI 的团队。可验证下一信号：该改动是否被 backport 到发布分支，以及分片 CI 失败率是否下降。
对依赖 PyTorch CI 稳定性的团队，减少非产品缺陷导致的测试红灯可降低排查成本；但该改动不涉及性能、API 或功能，商业影响有限。
若类似断言在其他测试文件中存在，可能继续出现同类分片失败；观察是否出现批量清理 handler 断言的后续提交。