tractor/ai/prompt-io/claude/20260406T222648Z_f086222_pr...

1.4 KiB
Raw Blame History

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 doesnt actually resolve this race.

Response summary

Traced the exact scheduling sequence across three concurrent tasks to show that the per-ctx_key locking change doesnt close the fundamental gap:

  • maybe_open_contexts finally pops the lock and sets no_more_users in the exiting callers 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_ctxs inner finally (before acm __aexit__)

Files changed

No code changes — analysis only.

Human edits

N/A — diagnostic output, no code generated.