Idle-peer notices are batched and capped so they cannot flood your terminal.
What's wrong with this entry?
Notices about idle peer sessions are now collected rather than printed one at a time: they are held for 500ms, flushed early once 50 pile up, and limited to 10 shown per rolling minute with the rest collapsed into a summary line.
- Notices whose session no longer matches the current conversation are dropped if you clear the conversation inside the batching window.
- Notices that arrived before the view mounted are replayed, also capped at 10 with the remainder summarised.
- The batching is wired into the REPL unconditionally; what decides whether peer idle notices are produced at all sits outside this code.
recorded in the last minute.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
Messages injected by a host are classified separately from peer messages
Both mention cross
-
v2.1.234
Cross-session control requests check ids more carefully
Both mention cross
-
v2.1.234
Notice acks now wait for the record to persist
Both mention cross