Description of the problem

Currently, the execution of the plan could make XWiki crashes because of XWIKI-9046.

The issue is that when a rename is performing, 2 actions are done on the wiki:
1 - the document A is copied to the target B.
2 - the original document A is deleted.

What happens frequently is that XWiki crashes during the first step (out of memory). When we restart the wiki, we have both A and B in the wiki.

B is not even a valid copy of A, because it might have not copied the whole history (which causes the memory explosion).

Proposed solution

What would be nice is to detect, when the migrator is restarted, that a bad copy of A already exists and delete it before we move A to B.

Use case:

• softec is running the migrator
• XWiki crashes (out of memory)
• softec restarts the wiki and launch the migrator
• XWiki does not crash because, at that time, there is more available memory.
• Since B exists, the computed plan about A is different than the first execution: it proposes to rename A to B_2 (it's a feature ).

What softec legitimately expects is to get the same plan the second time.

It won't fix XWIKI-9046 but at least, the wiki would be migrated at the end.

Alternative

A nice solution could be to be able to look at last migrator execution (since the status is serialized) and to be able to resume the execution of the plan after a crash. However that could be quite complex and the proposed solution (thanks to softec) could achieve the same goal without too much pain.

Other

The proper solution of course is to implement XWIKI-12184. But it is too complex and risky to be done on a 7.4.x version, and we need the migrator to work NOW.