There are no differences between OS and Enterprise. FinalityFlow will, left to its own devices, ensure everyone gets a copy of the transaction. There are a few things to be aware of:
- If you're potentially racing with another node, you may of course end up creating and trying to finalise a transaction that conflicts with another. The flow will then throw a notarisation exception. In some use cases you can simply retry in a loop until it succeeds.
- A very common case where this can occur is when using reference states in Corda 4. If you're referencing some data and then your transaction happens to occur at the same moment as the reference states are updated, you'll conflict and FinalityFlow will throw an exception. To simplify this, there is a WithReferencedStatesFlow that invokes the provided lambda to get a subflow and then invokes the subflow in a loop. In the common case it'll run only once, but if the reference data has been updated, the subflow may be run multiple times until it commits.
- The FinalityFlow currently sends transactions to counterparties serially. If one participant is offline, the others won't be sent the transaction until the first comes back online. This is a major limitation that we want to address soon.
Corda provides what's known as eventual consistency - nodes can have different views of the ledger at different times but will eventually get in sync. When everyone is online the gap may be less than a second, but if nodes start dropping offline then it can of course take longer. As long as you don't kill a flow it'll eventually complete.