This bug has been resolved in previous versions. See: https://r3-cev.atlassian.net/browse/CORDA-3095
The solution applied in the aforementioned ticket is not completely future-proof, so we should give it another though before deciding whether we will merge the bug fix as-is in subsequent versions.
The main problem is the following: the original bug fix is inspecting the stack trace of the error and identifies cases where the flow is ReceiveFinalityFlow and the flow failed when ReceiveTransactionFlow was at the top of the stack. This is safe for previous versions, since the structure of ReceiveTransactionFlow is relatively stable and consists of an initial session.receive and then invocation of some sub-flows. However, this will not necessarily be true for future versions. If ReceiveFinalityFlow is evolved in a way that more receive invocations happen, the previous criteria might be satisfied in cases where the associated transaction has already been finalised. The end result would be that a flow that has been finalised on a node will be removed from counterparties, which is not desired.