HDDS-16440. Handle directory purge submission failures

[rich7420]

What changes were proposed in this pull request?

Handle null responses from failed purge submissions at both batch flush sites, avoiding a NullPointerException. Stop processing the failed run before updating deletion counters.

Exact accounting for batches committed before a later failure is outside this change (HDDS-16437).

Related: #11118 changes the same batching code.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-16440

How was this patch tested?

• Six regression cases cover submission exceptions and unsuccessful responses in the first, middle and final batches, followed by a successful retry. All six fail without the fix and pass with it.
• Local checkstyle passed.
• Fork CI passed.
• 10×10 check for TestDirectoryDeletingService is running.

Generated-by: Codex (GPT-5)

[Copilot]

Copilot review overview

🟢 Approval recommended

Failure handling is correctly applied at both submission sites and regression coverage covers the relevant batch positions.

Review effort: Lite
Findings: None

What changed in this PR

Hardens directory purge submission handling so failed or null responses stop processing before deletion counters are updated.

Changes:

• Detect null and unsuccessful responses at both batch flush points.
• Add six regression cases covering failures in each batch position and successful retries.

File	Description
DirectoryDeletingService.java	Stops purge processing when submission fails.
TestDirectoryDeletingService.java	Adds parameterized failure and retry coverage.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[chihsuan]

Thanks for the patch! @rich7420

I looked into this more. IMO, this and HDDS-16437 are the same bug. The counters get updated without checking what was submitted. Skipping them on failure means successful batches never get counted, and 16437 would undo the new tests. I think we could fold 16437 into this PR and only count the batches that went through. What do you think?

[rich7420]

Thanks @chihsuan.

Skipping them on failure means successful batches never get counted

Agreed, the early return drops accounting for earlier successful batches. I'll include HDDS-16437 here and update the counters, metrics, and tests to cover partial success and retry.