From 34a15120583fa1b3829f1f9f2fa092015d7671fc Mon Sep 17 00:00:00 2001 From: Artur Shiriev Date: Mon, 3 Aug 2026 14:56:33 +0300 Subject: [PATCH] docs(deferred): the resolve-by-type 3.10 blocker is verified fixable The item already named the mechanism (a RecursionError tears down the trace function, and below 3.12 coverage traces rather than using sys.monitoring) and prescribed the fix. What was untested was whether the prescription works: a by-reference cycle records container.py:229 on 3.10, 5 runs of 5. That leaves the duplicated 8-line body as the sole gate, which is a judgement call rather than a defect, so the revisit trigger now says so. Co-Authored-By: Claude Opus 5 --- .../2026-08-01-resolve-by-type-inline.md | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/planning/deferred/2026-08-01-resolve-by-type-inline.md b/planning/deferred/2026-08-01-resolve-by-type-inline.md index d88f75e..bb1a64b 100644 --- a/planning/deferred/2026-08-01-resolve-by-type-inline.md +++ b/planning/deferred/2026-08-01-resolve-by-type-inline.md @@ -1,5 +1,5 @@ --- -summary: Inlining find_provider and resolve_provider into Container.resolve is a reproduced flat ~30 ns per by-type resolve (~60 ns on 3.10), held back by a CPython 3.10 coverage-gate failure and an 8-line duplicated body that must be edited in lockstep with resolve_provider. +summary: Inlining find_provider and resolve_provider into Container.resolve is a reproduced flat ~30 ns per by-type resolve (~60 ns on 3.10), held back solely by an 8-line duplicated body that must be edited in lockstep with resolve_provider -- the CPython 3.10 coverage-gate blocker is verified fixable in ~10 lines of test. --- # Inline the by-type resolve entry point @@ -42,6 +42,17 @@ It is not shippable as submitted: near-limit cycle unwinds where 3.10 suspends the trace function. Worth noting the prototyper *did* run 3.10 — without coverage — which is exactly why it missed this. + + **The fix is verified (2026-08-03), not just plausible.** A by-reference cycle + (`container.resolve_provider(provider)` on a mutual `Factory` cycle) records + `container.py:229` on 3.10, 5 runs out of 5. The mechanism is confirmed and + general: a `RecursionError` tears down the trace function, and below 3.12 — + where coverage traces instead of using `sys.monitoring` — anything executing + after the unwind in the *same* frame goes unrecorded. The same effect hit + `tests/providers/test_alias.py` in 3.2.0 and was fixed there by asserting + through `pytest.raises(match=)` so no line follows the recursion. So this + bullet costs roughly ten lines of test, and **the duplicated body below is the + only real blocker left.** - Two `architecture/` pages state the now-false singular and would need editing: `containers.md` and `validation.md` each name only `resolve_provider` as the path that compiles and dispatches. @@ -58,8 +69,8 @@ this session's workflow transcript directory. ## Revisit trigger -`resolve_provider`'s `RecursionError` handler gains a by-reference test so 3.10 -coverage holds, **and** a maintainer accepts the duplicated body as a standing -maintenance cost. Alternatively, the by-type path shows up as a measurable +A maintainer accepts the duplicated body as a standing maintenance cost — that +is now the sole gate, since the 3.10 coverage fix is verified to work and is +~10 lines of test. Alternatively, the by-type path shows up as a measurable bottleneck in a real integration profile, which would settle the trade on its own.