HDDS-16133. Make TestReconTasks EMPTY_MISSING check deterministic

[Eason09053360]

What changes were proposed in this pull request?

TestReconTasks#testContainerHealthTaskDetectsEmptyMissingWhenAllReplicasLost times out
intermittently in CI. Raising the timeout does not help: the logs show
Stored 1 MISSING, 0 EMPTY_MISSING for the whole 20s wait, so the container is classified into
the wrong state rather than classified late.

Recon picks EMPTY_MISSING over MISSING in ReconReplicationManager#isEmptyMissing, i.e.
getNumberOfKeys() == 0. The test set up its container with runTestOzoneContainerViaDataNode(),
which writes a block, and that block count reaches Recon as a key count: putBlock increments
the datanode block count, the datanode reports it as the replica key count
(ContainerData#setContainerReplicaProto -> setKeyCount(blockCount)), and the report handler
copies it into the container metadata (AbstractContainerReportHandler#updateContainerUsedAndKeys).
getNumberOfKeys() is then 1, so the replica-less container is recorded as MISSING.

The race: handleCreateContainer sends an ICR before any block is written, so the test's
replica-sync wait is already satisfied by a report carrying keyCount=0, and the datanode is
shut down right afterwards. handlePutBlock sends no ICR, so keyCount=1 can only arrive with
the next periodic full container report (1s in this test). Whether it lands before the shutdown
is purely a matter of timing, which is why the test only fails under CI load.

The fix creates the container without writing a block, so the datanode always reports a key
count of 0 regardless of report timing. The javadoc, which claimed the key count stays 0 merely
because Ozone Manager is bypassed, is corrected as well.

HDDS-16133.001.patch on the JIRA proposes the same approach; this change was arrived at
independently.

What is the link to the Apache JIRA

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

How was this patch tested?

• flaky-test-check 10x10 (100 runs), all splits green:
  https://github.com/Eason09053360/ozone/actions/runs/32270542328
• mvn -pl :ozone-integration-test-recon test -Dtest=TestReconTasks — all 6 tests pass.
• ./hadoop-ozone/dev-support/checks/checkstyle.sh — 0 failures.

The CI failure does not reproduce locally, since the race is always won on an unloaded machine.
The cause was confirmed by instrumenting the test instead: the registered replica consistently
showed keyCount=0, and both Recon's and SCM's numberOfKeys stayed 0 throughout. The local
runs were already hitting the post-fix state by accident; this change makes it guaranteed.

Generated-by: Claude Code (Claude Opus 5)

[Copilot]

Pull request overview

Makes the Recon integration test for EMPTY_MISSING classification deterministic by ensuring the test container is created without writing any block data, avoiding a timing-dependent key-count propagation race between datanode reports and Recon’s container metadata.

Changes:

• Update testContainerHealthTaskDetectsEmptyMissingWhenAllReplicasLost to create the container via an explicit CreateContainer command (no block write), keeping numberOfKeys == 0 reliably.
• Correct the test javadoc to reflect the actual reason the key count stays 0 (empty container / replica key count) rather than “bypassing OM” alone.

---

💡 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! @Eason09053360 LGTM +1

I left one optional nit about simplifying the Javadoc.