Goal / Objective

• Add targeted unit tests for the helper responsible for checking whether there is enough disk space to allow spilling, ensureSufficientDiskSpaceForSpilling.

• Validate that ensureSufficientDiskSpaceForSpilling:

• • Correctly distinguishes between sufficient and insufficient free disk space.

• • Enforces any thresholds / safety margins consistently.

• • Surfaces clear failures (status/exception/invariant) when disk space is not sufficient

---

Context & Background

• The server uses disk‑based spilling (e.g., for sorters and related components) when in‑memory usage exceeds certain limits.

• To avoid running the system into critically low disk space, we have logic that checks whether there is sufficient free disk space before allowing spill operations. This logic is encapsulated in the helper ensureSufficientDiskSpaceForSpilling.

• The helper is expected to:

• • Consult some notion of available disk space.

• • Compare that against configured or built‑in thresholds for spilling.

• • Decide whether to allow spilling to proceed or to fail / block the operation.

• At present, this behavior is not covered by a dedicated unit test suite, which makes it harder to:

• • Safely refactor spilling disk‑space checks.

• • Evolve thresholds or configuration without introducing regressions.

---

Acceptance Criteria

Test Coverage

• A dedicated cpp unit test suite in mongo/db/storage/spill_util_test.cpp exists for ensureSufficientDiskSpaceForSpilling that covers, at minimum:

1. 1. Clearly sufficient disk space

• • • Free disk space is well above the threshold.

• • • The helper succeeds (e.g., returns an OK status / does not throw).

1. 1. Clearly insufficient disk space

• • • Free disk space is well below the threshold.

• • • The helper fails predictably:

• • • • Returns a non‑OK status, or

• • • • Throws a well‑defined exception, or

• • • • Triggers a clear invariant, depending on the contract.

1. 1. Boundary / edge conditions

• • • Free disk space exactly at the threshold.

• • • Free disk space just above the threshold.

• • • Free disk space just below the threshold.

• • • Each case has a clearly documented expected outcome (allow vs. disallow).

1. 1. Configuration interactions (if applicable)

• • • If the helper respects a server parameter / knob (e.g., a minimum free‑space requirement), tests vary that parameter and validate:

• • • • A tighter configured limit causes more scenarios to be rejected.

• • • • A looser limit allows more scenarios to pass.

1. 1. Error / environment handling (if applicable)

• • • If the helper can see an I/O error or “unknown free space” result from the environment, its behavior in that scenario is tested and documented (e.g., conservative failure, or a specific error status).

Test Quality

• Tests are self‑contained, fast, and do not depend on actual disk usage; they can use the mock disk space usage failpoint when appropriate.

• Expected behaviors are described in comments or test names, so future maintainers can understand the intended policy from the tests alone.

• Tests are added to a spill_util_test.cpp file and we modify the directorie's BAZEL file ensure that these tests build in the correct unit test group

• Obvious code duplication is minimized by using helper functions and/or test fixtures across the different unit tests.

---

Constraints & Out of Scope

• No change to production behavior:

• • This ticket is limited to unit testing the current semantics of ensureSufficientDiskSpaceForSpilling.

• • It does not change the implementation or the thresholds themselves.

• No new configuration knobs:

• • Adding or redesigning server parameters for disk‑space management is out of scope.

• No broad refactor of spilling logic:

• • The work does not aim to redesign how spilling is triggered or how much is spilled; it only validates the sufficient‑disk‑space check.

• •