Problem When several changes are added to the same release note at the same time, for example by a script or a client posting to the REST API in parallel, most of the requests go wrong:
- some fail with a 500 error ("Failed to save the page [...]") or a 404 error ("The page [...] holds no change.");
- some succeed with a 201 that points to the same page as another request, and only one of those changes is kept: the others are lost without any error;
- some entry pages end up holding several change or entry objects, so the change is listed several times in the release note.
With 8 requests in parallel, about half of them fail, and about one entry page in five holds more than one change. The overwritten changes can't be recovered from the page history. Creating the changes one after the other works. Cause Concurrent requests compute the same next entry number. They are handed the same instance of the new page by the wiki's document cache and fill it at the same time, and a request whose insert collides with a page created in the meantime fails instead of moving on to the next number. 2.6.1 and earlier only had the colliding number (RN-88 made the window small), since the entry page was filled through a copy. |
