[ISSUE #10941] Retain receipt handles when cleanup submission is rejected

[Aias00]

What does this PR do?

Prevents offline receipt-handle cleanup from silently losing a removed group when its worker queue cannot accept the task. The cleanup executor now rejects explicitly, and clearGroup restores the group for the next scheduled retry.

Test

• mvn -pl proxy -Dtest=DefaultReceiptHandleManagerTest test
• Adds a regression that shuts down the cleanup executor and verifies the receipt-handle group remains tracked.

Closes #10941.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 85.71429% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 48.50%. Comparing base (293f588) to head (422624f).

Files with missing lines	Patch %	Lines
...y/service/receipt/DefaultReceiptHandleManager.java	85.71%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             develop   #10942      +/-   ##
=============================================
- Coverage      48.62%   48.50%   -0.13%     
+ Complexity     13692    13653      -39     
=============================================
  Files           1381     1381              
  Lines         101464   101469       +5     
  Branches       13187    13188       +1     
=============================================
- Hits           49337    49217     -120     
- Misses         46142    46240      +98     
- Partials        5985     6012      +27     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[RockteMQ-AI]

Summary

Solid fix for preventing receipt handle loss when the cleanup thread pool rejects the submission.

The change catches RejectedExecutionException when submitting the cleanup task and restores the handle group to the map via putIfAbsent(), ensuring the handles are retained for retry in the next schedule cycle. This prevents data loss under high load when the thread pool queue is full.

The explicit AbortPolicy on the thread pool constructor is good practice — it makes the rejection behavior explicit rather than relying on the default.

Test coverage validates the fix by mocking a scenario where the executor rejects the task and verifying the handles remain in the map.

LGTM.

---

Automated review by github-manager-bot

[Aias00]

Superseded by #10934, which now contains both asynchronous cleanup-failure and task-submission-rejection handling plus their regression tests.