The actor loop unwraps handle_incoming (core-shared/src/actor.rs:202, fac5569), so any error below it ends the connection. Five asserts sit on that path: the 5-second age check on requested_history_batches (actor.rs:222), the batch target equality in push (actor.rs:247), server_time.is_some() inside chathistory batches (handlers.rs:139), and the two batch id checks on message and BATCH close (handlers.rs:358, 532). Loud failures were the right call during labeled-response bring-up, and the review on the chathistory PR agreed they'd become warn-and-skip once that settled. #136 tested against seven public networks, which is the point where a stranger's server gets to decide whether the client stays up.
Turn each of those into a warn! carrying the offending line, then skip it. The run loop logs an Err from handle_incoming and keeps reading. A protocol error on one line shouldn't tear down a connection the user is typing into. The stale-request case gets a pruning path (drop the entry, warn) instead of an assert. The two dbg! calls on ChannelMODE and TOPIC (handlers.rs:55, 63) become debug! under tracing while you're there.
Spec
- Uplink - the connection these handlers keep alive
Acceptance criteria
- No
assert! or assert_eq! remains on the incoming-message path in core-shared
- A server line that fails a handler is logged with the raw line and the connection stays up, verified by scripting a malformed BATCH (unknown reference, mismatched close) through a mock connection
- A history request that never gets its batch is dropped from
requested_history_batches with a warning
dbg! doesn't appear in core-shared/src
Out of scope
Blocked by #30, since #136 reshapes the batch tracking these asserts sit in. Blocks nothing.
The actor loop unwraps
handle_incoming(core-shared/src/actor.rs:202, fac5569), so any error below it ends the connection. Five asserts sit on that path: the 5-second age check onrequested_history_batches(actor.rs:222), the batch target equality in push (actor.rs:247),server_time.is_some()inside chathistory batches (handlers.rs:139), and the two batch id checks on message and BATCH close (handlers.rs:358, 532). Loud failures were the right call during labeled-response bring-up, and the review on the chathistory PR agreed they'd become warn-and-skip once that settled. #136 tested against seven public networks, which is the point where a stranger's server gets to decide whether the client stays up.Turn each of those into a
warn!carrying the offending line, then skip it. The run loop logs anErrfromhandle_incomingand keeps reading. A protocol error on one line shouldn't tear down a connection the user is typing into. The stale-request case gets a pruning path (drop the entry, warn) instead of an assert. The twodbg!calls on ChannelMODE and TOPIC (handlers.rs:55, 63) becomedebug!under tracing while you're there.Spec
Acceptance criteria
assert!orassert_eq!remains on the incoming-message path in core-sharedrequested_history_batcheswith a warningdbg!doesn't appear in core-shared/srcOut of scope
unwraps inSupport::set, which the ISUPPORT trim ticket (Trim ISUPPORT parsing to the tokens Uplink uses #144) ownsBlocked by #30, since #136 reshapes the batch tracking these asserts sit in. Blocks nothing.