ci: 加一条"慢 runner"腿，把时序假设变成当场失败 - #29
Merged
Merged
Conversation
main 之前因为"睡 0.3 秒后至少 3 次检查"拿到 2 而红过一次（#28 修掉了那条断言）， 但根因不是那一条测试：只要断言里含有"这台机器够快"，下一次还会随机红。这条腿把 那种机器搬进 CI：注入线程延迟，于是这类测试当场失败。 关键点：**注入必须是不对称的**。把测试自己的 time.sleep 也一起拉长会保持所有比例， 等于什么也没测（测试睡 0.3s 变 0.9s，循环的 wait(0.05) 也变 0.2s，照样跑满 6 次）。 真实世界的慢是单边的：被测代码在自己线程里的每次等待都排在 runner 当前负载之后， 而测试那句固定睡眠不会跟着变长。所以 tests/conftest.py 只拖慢**非主线程**的 Event.wait 与 time.sleep（后台线程自我节流只有这两条路）；时钟一律不碰——动 time.monotonic 毁掉的是截止时间本身，不是模拟负载。 自证与防退化： - 报告头打出横幅（+0.15s per worker sleep/wait），CI 那一步 grep 它：一条静默失效 的注入会把这条腿变成空跑，而输出仍然是绿的。 - tests/test_timing_guard.py 直接测量机制：开着时工作线程变慢、主线程不变；关着时 两者都不受影响。环境变量写成非数字时直接报错退出，而不是静默关掉。 验证：把 tests/test_health.py 换回 #28 之前的版本并注入延迟，整套当场失败，报的 正是 CI 那条 AssertionError: 2（其余 414 全过）；用当前版本则 415 全过（注入与 正常各跑一遍）。 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
它模拟的是"工作线程等待/被调度得晚"，不是"工作线程缺 CPU"：在主线程上固定睡一段 等待 worker 真正干活的测试不受它影响，仍然依赖 runner 够快。不写清楚的话，这条腿 的绿很容易被读成"已经没有时序假设了"。 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>
This was referenced Sep 20, 2026
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
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.
#28 修掉了那条抖动的断言，但根因不是那一条测试：只要断言里含有"这台机器够快"，下一次还会随机红。这个 PR 把"慢机器"搬进 CI，让这类测试当场失败。
注入必须是不对称的（这是整个设计的要点）
如果只是把"所有 sleep 一起拉长"，比例不变，什么也测不出来：测试睡 0.3 秒变成 0.9 秒，循环的
wait(0.05)也变成 0.2 秒，照样跑满 6 次。真实世界的慢是单边的：被测代码在自己线程里的每次等待都会排在 runner 当前负载后面，而测试那句固定
time.sleep(0.3)不会跟着变长。所以tests/conftest.py只拖慢非主线程的threading.Event.wait与time.sleep——后台线程自我节流只有这两条路。时钟（time.monotonic）一律不碰：动它毁掉的是截止时间本身，而不是模拟负载；sleep(0)是让出时间片、不是等待，也保持原样。一条静默失效的守卫比没有守卫更糟
所以它必须能自证：
thread latency: +0.15s injected into every worker sleep/wait，CI 那一步grep 它——否则这条腿可能安静地空跑，而输出仍然是绿的（grep 那一步因此不加-q，因为-q会把报告头吃掉）。tests/test_timing_guard.py直接量机制，而不是相信开关的名字：开着时工作线程的Event.wait(0.01)确实变慢、主线程不变；关着时两者都不受影响。PONTE_TEST_THREAD_DELAY=abc直接报错退出，而不是静默关掉。新增的 CI 腿
Timing guard (injected thread latency)，ubuntu + 3.12，PONTE_TEST_THREAD_DELAY=0.15。只跑一个 OS/版本：它的价值在确定性，不在覆盖率（版本/平台差异由上面的矩阵负责）。本地也能用同一个变量复现，README 与 CONTRIBUTING 都写了。验证：它抓得住吗
把
tests/test_health.py换回 #28 之前的版本，再按这条腿的方式跑：——报的正是当初 main 变红的那一条，而且从"偶发"变成"每次"。换回当前版本后，注入与正常两种条件下各跑一遍都是 415 passed；
ruff、mypy（本机与--platform linux）、_smoke_test.py全过。一点诚实说明
这条腿能保证"不再有时序断言悄悄溜过"，但不能保证 0.15 秒就是最好的量级：它比我见过的真实抖动（每轮 0.12 秒）略高一点。如果将来某条行为正确的测试在这里失败，正确反应是检查它是否真的在断言行为，而不是把数字调小——数字调小等于把守卫关掉一半。