TrashEntryServiceImpl.deleteEntries() selects TrashEntries by "trashEntryPersistence.findByGroupId(groupId)" which internal does the sorting on create date,
Because of MySQL does not support ms in Date type, plus all sorts of cache and hibernate buffering, logically first created entry does not necessarily have an older create date.
As a result, the result List<TrashEntry> does not reflect the logical order when they were created.
In this breaking case : https://test-14-2.liferay.com/job/test-portal-pullrequest-backend%28master%29/387/group=14,label_exp=!test-14-2/testReport/junit/com.liferay.portlet.wiki.trash/WikiPageTrashHandlerTest/testTrashBaseModelAndParentAndDeleteGroupTrashEntries/
We have a WikiNode and a WikiPage. We move the page to trash first(logically), node after it. But the List<TrashEntry> actually holds WikiNode at index 0, WikiPage at index 1, because of the create data disordering.
So it removed WikiNode first, which cascadly removed all its pages including the one at index 1.
Later after we finish the WikiNode removal, move on to the wikipage trash entry, we will be removed something that is already removed, raising this error.
There is no way we can fix or safely rely on the create date for this logic.
The only safe way to fix it will be:
Before remove each TrashEntry, refetch it again, only actually remove it when you are still able to see it. If you are not seeing it, it means the previous TrashEntry removal already cascadly removed it, then we can just skip it.