floatdrop / moq-go / 31727022073

89%

Build Type

push

github

Committed by web-flow

Commit Message

test: reach the relay's transport-failure branches, and fix the RejectError hang (#77)

The relay's "write failed" / "reply failed" branches were unreachable: every
hermetic test runs over sessiontest's in-process pipes, which never fail a
write, and the only way to break one was CloseWithError, which takes the whole
conn down before the branch under test can run.

sessiontest.Faulty wraps any session.Conn and consults a hook before each
operation on the conn and every stream it hands out. Faults are injected in
FRONT of the wrapped call, so a failed Write puts no bytes on the stream and a
failed OpenStream consumes no credit; wrapping panics rather than silently drop
PrioritizedSendStream / ReliableResetStream, which priority_test.go already
builds.

Branches it unlocked: both namespace REQUEST_OK failure paths, handlePublish's
two-part registration rollback, and two auth-denial arms that had no test.
Plus metric label values and message Type/ParamID naming invariants swept from
newMessage and kindOf rather than a table of literals.

It also exposed a real defect. Request.RejectError returned early when its own
REQUEST_ERROR write failed, skipping the CancelRead and FIN below it, so the
request stream was left open both ways and the peer blocked forever on a
response that could never arrive. draft-19 §3.3.3 covers this: "Receivers
cancel requests if they are unable to or choose not to respond ... using
RESET_STREAM for a direction they are sending and STOP_SENDING for a direction
they are receiving" — which is the existing resetStream helper. Attempting the
FIN anyway would have violated §3.3.2's MUST NOT, and because Marshal buffers
the frame before WriteFrame, a short write can leave a partial frame that
RESET_STREAM discards and a FIN would reliably deliver.

Every test verified red first by mutating the behaviour it protects. Two
mutations changed what shipped: the publish-rollback test's first version
re-published the SAME track under the same a... (continued)

Coverage Stats

143 of 150 new or added lines in 2 files covered. (95.33%)

7 existing lines in 2 files now uncovered.

9178 of 10388 relevant lines covered (88.35%)

2.01 hits per line