With the current implementation it may also happen that a commit is exposed, which is later marked as failed.
Unfortunately this can still happen, even with readRevId only updated for trunk.
MongoMKBranchMergeTest#concurrentNonConflictingMerges doesn't expose this problem because the changes are non conflicting. The test only exercises concurrency.
I think the test in
OAK-566 shows what happens when commits are concurrent and conflicting (to some degree).
I still think it was a good move to limit the usage of headRevId because it makes the implementation simpler and should have better concurrency with branch commit (no need to update headRevId in this case). We just have to keep in mind the problem stated in the description of this issue is not yet completely solved. I'd say we can follow up in