Is applyWrites allowed to split operations across multiple commits?

[DavidBuchanan314]

A sub-optimal but very easy way for a PDS to support applyWrites would be to create a separate commit for each operation. Is this valid? This could potentially break atomicity assumptions made by the writer - but would that be a bad assumption on the writer's part, or a bad PDS implementation?

[bnewbold]

Interesting question! When I implemented adenosine I definitely did it the other way around: every mutation was a batch-write, and createRecord (etc) just resulted in a batch op with a single operation.

I think I would lean towards this being inadvisable but probably need to think it through more. I think it is good to have either all the ops succeed or fail together, no half-processed. Additional repository events create commit churn, which means extra MST nodes and events on the wire (aka, resource amplification). I think there are hypothetical situations where having multiple ops together would be important, like a "move record" (delete old entry, create new identical entry).

On the other hand maybe i'm being too conservative.

cc: @dholms (who may take a while to respond)

[devinivy]

I think there are hypothetical situations where having multiple ops together would be important.

Yeah, there definitely are 👍 One example is creating a post with an associated threadgate (#1561). Clients want to ensure that both of those records are created in a single write, so that there's no commit on which the repository reflects the post record without its threadgate. Another concrete example is if we had upvotes and downvotes: switching an upvote to a downvote might consist of a write that deletes the upvote and creates the downvote.

In my view data integrity is difficult enough in the distributed setting that we should hold on tight to the facilities that we do have to help clients contend with correctness, and atomic repo writes are a super useful/fundamental tool. While clients can't control whether the ops in their writes are processed atomically by upstream services, they might at least have some control over what states the repo can be observed in.

That thought process aside, need to think more about whether there's actually any compatibility issue that could crop-up 🤔 It's possible that there isn't, but I'm not entirely sure.