gsvarovsky
commented
3 years ago Constraint Break-Fix Pairs
An update arriving at clone1 can cause an immediate constraint apply-fix. These transactions are separate in the journal (but appear as one in the app updates). So when another clone revs-up from clone1, it receives the causal operation first, which it may immediately react to with its own apply-fix, possibly borking some consequent state.
This is fixable by batching a break-fix pair in a rev-up. The receiving clone notes that the break transaction is followed by the fix, and applies both atomically. Then, the violation will not occur (generally – the state could still violate for some other reason). This requires a flag in the journal that a transaction was (followed by) a constraint application.
When applying a constraint, conflict resolution assertions can be made that are published as operations on the state. Multiple clones receiving conflicting operations can therefore issue duplicate resolutions.
During normal operation, these duplicate assertions are normally idempotent. However, if there is time for some clone to take actions consequential to the resolved state, which alter it further, these have the potential to be affected by late-arriving constraint assertions. Such late arrivals can easily arise due to a rev-up.
In general, deletion assertions are fine because they will be affecting triples already deleted. But insertion assertions can override user assertions.
Most generally stated, this problem relates to opaque intentions in the whole system, including external and human actors. Ordering does not matter to the CRDT but it may matter to them.
This is under investigation in https://github.com/m-ld/m-ld-security-spec/issues/2