FIX initiator logon/logout handling

[dilanperera87]

We have built a FIX client application that connects to a trading venue and noticed a sequence gap after a failed logon attempt. Below is the scenario:

1. The client connects to the FIX server and sends a Logon (A) with MsgSeqNum 1 — the Logon contains an expired password.
2. The server responds with a Logout (5), indicating the password is expired.
3. The client generates a Logout (5) with MsgSeqNum 2 and attempts to send it, but the message fails to send because the connection has already been terminated by the server.
4. In the next logon attempt, the client sends a Logon (A) with MsgSeqNum 3, since it previously generated a Logout message with MsgSeqNum 2.

Is step 3 in the above scenario correct? From my understanding, the client should not respond to the Logout (5) message received for the logon failure. This triggers resend request from the server side after the failed logon attempt.

What are your thoughts on this?

[chrjohn]

To be honest, sending a Logout in step 3 also looks a little unnatural to me. However, I could not find anything which contradicts this logic looking (briefly) at https://www.fixtrading.org/standards/fix-session-testcases-online .
Moreover, if you look at case 1S in https://www.fixtrading.org/standards/fix-session-testcases-online/#sellside-oriented-session-acceptor-logon-and-session-initiation-test-case it even is suggested to drop the connection without sending a Logout when receiving a Logon which is unauthenticated:

Disconnect without sending a message (Note: sending a Reject or Logout(35=5) would consume a MsgSeqNum(34)).

But this is just a brief analysis.