Joseph Doherty
a71663a2a2
The pre-check measures the command envelope while Sequence is still 0, and an unset protobuf field costs nothing to encode -- so the measured size is a lower bound on the frame WriteLoopAsync emits after GWC-28 stamps the sequence. Being a lower bound is the right kind of conservative for the knownSize question the comment answers, and the wrong kind for the pre-check itself: it admits an envelope in the last eleven bytes of the range that the writer then rejects with a session-fatal MessageTooLarge. Compare against MaxMessageBytes - MaxSequenceEncodingBytes (1 tag byte + a 10-byte varint, the widest 64-bit field encoding) and say in the comment that the pre-check is a lower bound relying on that allowance. Not reachable under the shipped validator (caller-controlled commands arrive through gRPC capped at least 64 KiB below the pipe max, gateway-authored commands are tiny), so this closes the argument rather than a live defect. The existing CommandTooLarge test still passes unchanged.