If CheckEntryMessageListener process failed, all datas won't deleted

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 6.2.X EE, Master
• Fix Version/s: 6.2.X EE, 7.0.0 DXP FP20, 7.0.3 CE GA4, 7.0.0 DXP SP4, 7.0.X EE, 7.1.X, Master
• Component/s: ~[Archived] WCM
• Labels:
  • 62-ee-sp20
  • ee-ts
  • liferay-digital-enterprise-70-sp4
  • liferay-fixpack-de-20-7010
  • liferay-fixpack-portal-152-6210
• Branch Version/s:
  7.0.x, 6.2.x
• Backported to Branch:
  Committed
• Git Pull Request: https://github.com/brianchandotcom/liferay-portal/pull/43027

Description: If we empty Recycle Bin data in UI, it will delete those right datas even though one data can't be delete (due to exception occur). However, when CheckEntryMessageListener process failed, all datas won't deleted.

Steps:
1. Create one blog "blogEntry" (entryId=32843) and document "dlFileEntry".
2. Remove them to Recycle Bin.
3. Directly delete "blogEntry" from blogsentry table.
delete from blogsentry where entryId=32843
4. Go to Recycle Bin. Execute empty the Recycle Bin.
Result: "dlFileEntry" will be deleted and the below error printed in log. It can explain that even though the delete process failed, but document can be deleted successful.

com.liferay.blogs.kernel.exception.NoSuchEntryException: No BlogsEntry exists with the primary key 32843

5. Create another document "dlFileEntry1", and then remove it to Recycle Bin.
6. Close bundle. Set the below properties in portal-ext.
trash.entry.check.interval=2
trash.entries.max.age=3
7. After 3 mins, restart bundle.
8. When com.liferay.trash.web.internal.messaging.CheckEntryMessageListener executes, it should delete "blogEntry" and "dlFileEntry1" from Recycle Bin. However, due to "blogEntry" data is lost from blogsentry table. It will deleted failed. This affects "dlFileEntry1" can't be deleted. This is inconsistent with empty the Recycle Bin.

Expected behavior: Even though "blogEntry" can't be deleted, it shouldn't affect "dlFileEntry1" can't be deleted. That is to say, one delete model process failed, it shouldn't affect the whole delete process failed. For example, when CheckEntryMessageListener executes and there are 10,000 datas matched with this delete situation. If due to one data exist data integrity issue so that it can't be deleted, and this will cause other 9999 datas can't deleted. It is better for me to let other 9999 datas deleted successful.