The protocol_admission_lock is now held for the entire duration of the publish closure (websocket serialization + send), whereas before this PR publish() ran without it. During this window, all protocol and sidecar pool admission (add_validated_protocol_transaction, add_validated_sidecar_transaction, add_transaction_and_subscribe) blocks on the same mutex.

If the websocket publish experiences backpressure or latency (e.g., slow consumer, large flashblock serialization), pool admission stalls for all submitters until it completes. This is the intended tradeoff for atomicity, but worth confirming that the publish path cannot block long enough to cause transaction submission timeouts or RPC deadline violations under production load.

The lock intentionally serializes admission with publication and expiry so an observed deadline frees the same-nonce slot before admission proceeds. WebSocketPublisher::publish (crates/builder/publish/src/publisher.rs) performs synchronous JSON serialization, a ring-buffer update, and tokio broadcast::Sender::send, not a socket send. Per-client network sends run separately in BroadcastLoop; replay snapshots release the ring-buffer read lock before awaiting sends. Slow consumers therefore do not backpressure this admission lock. Serialization still contributes to lock hold time; this inspection does not establish production latency bounds, but it does not identify a timeout regression requiring a code change.

🤖 Reply generated with Toshi

published_flashblock is set to Some(position) here but is never reset to None when a new block starts (e.g., in on_canonical_state_change). This works today because expire_published_locked uses a monotonic >= guard at line 443 and ensure_not_published_expired uses is_batch_expired which correctly handles cross-block semantics (a stale published position from block N won't falsely reject transactions targeting block N+1).

However, the stale published_flashblock from a previous block means ensure_not_published_expired performs a non-trivial is_batch_expired evaluation on every admission for the rest of the node's lifetime, even when no flashblocks are being built (e.g., sequencer downtime). More importantly, the implicit invariant that the stale position is always safe relies on is_batch_expired's block-vs-flashblock interaction. An explicit reset in on_canonical_state_change (e.g., *self.published_flashblock.write() = None; under the admission lock) would make this simpler to reason about and remove the coupling.

The retained position is intentional across ordinary block transitions: canonical maintenance can arrive after flashblocks for the next block have already been published. An unconditional reset would erase that newer deadline protection and admit already-expired submissions.

I did reproduce a correctness issue on reorgs: a position from the old branch rejects otherwise-valid rebuilt-block deadlines and suppresses expiry at lower block/index positions. The follow-up resets the watermark only for PoolUpdateKind::Reorg, while holding the admission lock. Regression tests cover protocol and sidecar admission/expiry after both a lower-height rebuild and a same-height flashblock-index restart, plus preservation of newer publication state during an ordinary commit. The reorg regression fails before the fix.

No performance bottleneck was demonstrated for retaining the position during ordinary commits, so I have not added a broader reset or a performance refactor.

🤖 Reply generated with Toshi