Drill 14 — NextExpectedMsgSeqNum (789), the other recovery handshake

[sylvioCampos]

Drill 07 teaches recovery the classic way: notice the inbound sequence number is too high, send a ResendRequest, receive the replay. There is a second mechanism, and docs/drills/06-seqnum-persistence.md names it while declining to cover it:

Some venues let you negotiate the expected sequence number on the Logon itself (NextExpectedMsgSeqNum, tag 789), which changes the recovery handshake. quickfixgo supports it via EnableNextExpectedMsgSeqNum; this lab does not use it, since the classic ResendRequest path is the one to understand first.

That was the right call for a first pass. It leaves a reader who connects to a venue using tag 789 watching a recovery that does not match anything the lab showed them.

What the drill should teach

• Each side declaring on its Logon what it expects to receive next, so the gap is known before any application message flows
• The resend that follows being implicit — no 35=2 on the wire at all — which is the part that confuses someone expecting drill 07's trace
• Why a venue would prefer it: one fewer round trip, and no window where both sides are talking past each other
• The failure mode: enabling it against a venue that ignores tag 789, or not enabling it against one that requires it

Implementation note

quickfixgo already implements this — handleLogon evaluates tag 789 when EnableNextExpectedMsgSeqNum is set and generates a SequenceReset itself. So this is mostly a config profile and a drill, not new engine work.

The drill should reuse drill 07's exact scenario — same order, same three executions generated while disconnected — so the two wire traces can be compared side by side. That contrast is the whole point.

Acceptance

• docs/drills/14-next-expected-seqnum.md, structured as a comparison against drill 07
• A test asserting recovery completes with no 35=2 on the wire
• Drill 06 links here rather than leaving the reference hanging