The store now checks inside the save transaction, with a pessimistic lock on the document row, that the stored revision is still the one the saved document was loaded from. A save that loses a race throws the new DocumentRevisionConflictException instead of overwriting the other save. This also covers a document saved as new that was created in the meantime, and cluster setups.
XWiki#addUserToGroup (the scenario of this issue), attachment uploads from the WYSIWYG editor (XWiki.WYSIWYG.FileUploader) and the save action retry on that conflict. The save action merges again, so a concurrent save that doesn't conflict, e.g. another user adding an attachment, no longer shows any error.
Scripts can retry too, with $services.merge.isDocumentRevisionConflict, and Java code with XWiki#updateDocument.
The check can be disabled with store.revisionCheck.enabled in xwiki.properties.
This was also behind some failures of RealtimeWYSIWYGEditorIT#dragAndDropFilesAtTheSameTime (XWIKI-22619): two users dropping files into a new page at the same time, and the second upload failed. On MySQL, MariaDB, PostgreSQL and Oracle, concurrent uploads forced into the race were all detected and retried, and every attachment was kept.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
