Problem Code/EntryVelocityMacros #handleAddAction computes the next entry name from the pages that already exist, then redirects the author to that name in the inline editor:
#set ($highest = $highestQuery.setLimit(1).execute())
... compute $nextUniqueNumber ...
$response.sendRedirect($xwiki.getURL(<...>.Entry###, 'edit', ...))
The new page only starts existing when the author saves. The window is therefore not milliseconds — it is the whole editing session. Consequence If two people click "Add ... Change" on the same release note before the first one saves, both compute the same Entry### name and both get an empty inline form for the same page. Last save wins, the other change is lost, and neither author gets a conflict warning. This is the workflow the application exists for (a release manager and a committer filling in the same release note). Possible fix Create the page immediately from the template (empty) before redirecting, or loop until an unused name is found. Secondary, same code The candidate query orders by doc.space desc, which is a string sort, so past Entry999 the highest space is Entry999 rather than Entry1000 and the number 1000 is handed out repeatedly. This needs ~1000 entries in one version space, so it is much less likely to be hit than the concurrency case. |
