In our production environment, we saw the following scenario:
They log on w/ 687
We send resent request from 684 to 0
They send a resend request (their #688)
They send gap fill from MsgSeqNum=684 to NewSeqNo=688.
They send us 689.
QF did not recognize that the resend request had been fulfilled, so it did not send another resend request when it saw 689.
The counterparty was never going to send us 688 otherwise - they had already sent it (and indeed we acted on it).
So we ended up not processing any of their messages (sequence number too high), and eventually disconnected.

We tracked the problem down to the
boolean verify(Message msg, boolean checkTooHigh, boolean checkTooLow)
method around line 1168. If the MsgSeqNum is at or beyond the end of the resend range waiting to be satisfied, then the resend request will be deemed satisfied. But for gap fills, it should really consider the entire range of the gap, i.e., MsgSeqNum to NewSeqNo - 1, which it does not. NB that in some scenarios, the next inbound message will clear the problem. But not in the one above.

We are running 1.2.1. Based on inspection of the code, I believe this also affects 1.3.x and 1.4.x.

Will attach a patch, diff.txt.