Fix: Channel failure on shm resize due to CacheMiss#254
Conversation
Combines the two independent fixes for the silent channel-death on mid-stream SHM resize (issue #253): - On reattach failure, recover instead of raising. A fast resize storm can dealloc the segment before we attach; broaden the catch to (ValueError, OSError) and drop to the shm-is-None ack path rather than killing the channel task. (from #254) - Swallow CacheMiss in _release_backpressure: the cached entry can be evicted by the reattach path before backpressure clears; a miss just means nothing to free, so keep acking. This is the specific crash #253 reports. (from #254) Retains the UninitializedMemory guards at the msg_id() call sites, which #254 lacks -- msg_id() raises UninitializedMemory on an uninitialized slot (the exact race), which would otherwise escape #254's buffer-id check and kill the task it aims to protect. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The attach-recovery + One gap worth closing before merge: the two I pushed a branch on top of this one that wraps both sites (treat uninitialized as skip/mismatch → drop + release) and adds a parametrized cross-process grow test (single grow / two successive grows / grow-on-first-message) alongside your
Both your repro and the new grow tests pass against it (16 passed). Happy to open it as a PR into your branch or you can cherry-pick — whichever you prefer. |
2 participants
If a
Publisherresizes SHM repeatedly, it can happen that the receivingMessageChanneleither fails to lease the block before it becomes deallocated, or that the associated block is no-longer leased and is deallocated when backpressure is cleared, resulting in an uncaughtCacheMissexception which kills the Task servicing the connection silently.The test case and hardening of message servicing in
MessageChannelin this PR likely closes #253.