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

1.8 KiB
Raw Blame History

Prompt

User asked to reproduce the exact assert not resources.get(ctx_key) crash originally seen in pikers brokerd.kraken backend via open_cached_client('kraken'). Key constraints from user:

  • In piker, kwargs were the same (empty) so all callers share one ctx_key = (fid, ())
  • The root issue is _Cache.locks being indexed by fid rather than ctx_key, plus the race window between values.pop() and resources.pop() in _Cache.run_ctx (the acm __aexit__ has checkpoints in between)
  • Mark the test @pytest.mark.xfail so it can be committed against the unpatched code and later adjusted once the fix from 9e49eddd is applied

User pointed to pikers open_cached_client('kraken') usage as the real-world pattern to model.

Response summary

Added test_moc_reentry_during_teardown which deterministically reproduces the teardown race:

  1. A cached_client() acm (no params, like kraken.api.get_client()) signals via in_aexit event when its __aexit__ starts, then sleeps to hold the window open
  2. use_and_exit task enters+exits the cached resource
  3. reenter_during_teardown waits on in_aexit then re-enters — landing exactly in the window where values is popped but resources still exists
  4. The old assert not resources.get(ctx_key) fires
  5. @pytest.mark.xfail(raises=AssertionError) catches it

Test confirmed: XFAIL with the exact traceback at _mngrs.py:327.

Files changed

  • tests/test_resource_cache.py — add test_moc_reentry_during_teardown xfail test fn

Human edits

None — committed as generated (pending user review).