53 lines
1.4 KiB
Markdown
53 lines
1.4 KiB
Markdown
|
---
|
||
|
|
model: claude-opus-4-6
|
||
|
|
service: claude
|
||
|
|
session: (ad-hoc, not tracked via conf.toml)
|
||
|
|
timestamp: 2026-04-06T22:26:48Z
|
||
|
|
git_ref: f086222
|
||
|
|
scope: code
|
||
|
|
substantive: true
|
||
|
|
raw_file: 20260406T222648Z_f086222_prompt_io.raw.md
|
||
|
|
---
|
||
|
|
|
||
|
|
## Prompt
|
||
|
|
|
||
|
|
User applied the per-key locking patch (`f086222d`),
|
||
|
|
removed the `@pytest.mark.xfail` from
|
||
|
|
`test_moc_reentry_during_teardown`, and found the
|
||
|
|
test STILL fails — now with `RuntimeError` instead
|
||
|
|
of `AssertionError`. Asked to diagnose why the fix
|
||
|
|
doesn't actually resolve this race.
|
||
|
|
|
||
|
|
## Response summary
|
||
|
|
|
||
|
|
Traced the exact scheduling sequence across three
|
||
|
|
concurrent tasks to show that the per-`ctx_key`
|
||
|
|
locking change doesn't close the fundamental gap:
|
||
|
|
|
||
|
|
- `maybe_open_context`'s finally pops the lock and
|
||
|
|
sets `no_more_users` in the **exiting caller's
|
||
|
|
task**
|
||
|
|
- But the actual resource cleanup (`values.pop`,
|
||
|
|
acm `__aexit__`, `resources.pop`) runs in the
|
||
|
|
**`run_ctx` task** inside `service_tn`
|
||
|
|
- A re-entering task creates a fresh lock (old one
|
||
|
|
popped), acquires immediately, and hits stale
|
||
|
|
`resources[ctx_key]` while `run_ctx` is still in
|
||
|
|
`__aexit__`
|
||
|
|
|
||
|
|
Identified three possible fix strategies:
|
||
|
|
1. Let `run_ctx` own lock release/pop after
|
||
|
|
`resources.pop()`
|
||
|
|
2. Add a "teardown complete" event that new callers
|
||
|
|
wait on
|
||
|
|
3. Move `resources.pop()` into `run_ctx`'s inner
|
||
|
|
finally (before acm `__aexit__`)
|
||
|
|
|
||
|
|
## Files changed
|
||
|
|
|
||
|
|
No code changes — analysis only.
|
||
|
|
|
||
|
|
## Human edits
|
||
|
|
|
||
|
|
N/A — diagnostic output, no code generated.
|