Context
Scheduled mutation run 29495843050 (2026-07-16, first green run after the baseline fix in #140) exercised 22 mutants across crates/comenqd/src/listener.rs, crates/comenqd/src/logging.rs, and crates/comenqd/src/worker.rs: 4 caught, 3 missed, 4 timed out, 11 unviable.
One of the missed mutants sits in the request-size guard in handle_client:
crates/comenqd/src/listener.rs:138:43: replace * with +
pub const MAX_REQUEST_BYTES: usize = 1024 * 1024; // 1 MiB
Replacing * with + changes the limit from 1 MiB (1,048,576 bytes) to 2,048 bytes, and the test suite still passes. A related mutant at the same location (replace * with /) timed out rather than being caught, which is a second signal that the exact value of MAX_REQUEST_BYTES is not pinned down by any test.
Analysis
The existing tests evidently check that oversized payloads are rejected and that small payloads succeed, but none of them assert on the actual byte threshold. A test that sends a payload just under, at, and just over the real 1 MiB boundary would catch both the + and the / mutation, and would also guard against accidental future changes to the constant.
Proposed next step
Add a focused unit or behavioural test for handle_client (or the constant itself) that asserts the accept/reject boundary sits at exactly 1,048,576 bytes, using payloads sized relative to MAX_REQUEST_BYTES rather than a hard-coded literal so the test tracks the constant if it is ever revised deliberately.
Context
Scheduled mutation run 29495843050 (2026-07-16, first green run after the baseline fix in #140) exercised 22 mutants across
crates/comenqd/src/listener.rs,crates/comenqd/src/logging.rs, andcrates/comenqd/src/worker.rs: 4 caught, 3 missed, 4 timed out, 11 unviable.One of the missed mutants sits in the request-size guard in
handle_client:Replacing
*with+changes the limit from 1 MiB (1,048,576 bytes) to 2,048 bytes, and the test suite still passes. A related mutant at the same location (replace * with /) timed out rather than being caught, which is a second signal that the exact value ofMAX_REQUEST_BYTESis not pinned down by any test.Analysis
The existing tests evidently check that oversized payloads are rejected and that small payloads succeed, but none of them assert on the actual byte threshold. A test that sends a payload just under, at, and just over the real 1 MiB boundary would catch both the
+and the/mutation, and would also guard against accidental future changes to the constant.Proposed next step
Add a focused unit or behavioural test for
handle_client(or the constant itself) that asserts the accept/reject boundary sits at exactly 1,048,576 bytes, using payloads sized relative toMAX_REQUEST_BYTESrather than a hard-coded literal so the test tracks the constant if it is ever revised deliberately.