monotonic-seconds-since-boot-uptime-dependent-test

Answer

Solution written to ~/solution.md and verified against a faithful reproduction (~/cb_repro/), since the actual get-h3/shim source isn't present in this environment.

Key findings

Root cause: The test anchors cb.opened_at = 999999.0 as a "far future" literal, but allow_request() compares against time.monotonic() (seconds since boot), not wall-clock time. The literal is therefore a fixed uptime of 11.574 days. Once now >= 999999.0 + cooldown (≈ 1_000_029 s for a 30 s cooldown), the circuit half-opens, the probe closes it, and the OPEN assertion fails — deterministically, only on long-lived hosts, and it "heals" on reboot.

Threshold confirmed empirically:

uptime=999998  -> allow_request=False
uptime=1000028 -> allow_request=False
uptime=1000029 -> allow_request=True   # 11.5744 days

Exact fix — don't poke state/opened_at with an absolute literal; construct the OPEN state through the real API so opened_at is "now":

-    cb.state = State.OPEN
-    cb.opened_at = 999999.0        # "far in the future"
-    assert not cb.allow_request()
+    cb.open()                      # opened_at = time.monotonic()
+    assert not cb.allow_request()

Stronger variant: monkeypatch/inject the clock and set opened_at = now (or now - cooldown/2), making the test fully uptime-independent.

Verification run:

BAD   (opened_at = 999999.0): health-check-ran
FIXED (opened_at = now)     : health-check-skipped
BAD   reproduces bug? True
FIXED skips health   ? True
2 passed in 0.00s

The document includes the full root-cause analysis, both fix options, runnable verification commands with expected output, and a prevention checklist (including a CI grep gate for opened_at = <large literal>).