---
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.