doc(coverage): re-measured, and the HA claim was about our CI

[kzangeli]

Re-measured on e0a5427. Both suites green — 627/627 mongoc, 577/577 corDB.

Run	Lines	Functions	Branches
mongoc	82.9% (26180/31573) ← 82.7%	95.7% (1312/1371) ← 95.1%	64.6% (18132/28078) ← 64.3%
corDB	79.2% (23496/29677) ← 78.9%	91.5% (1217/1330) ← 90.9%	61.8% (16717/27030) ← 61.6%

It was not the new tests

Four tests were added and everything rose, but the movement is corRest:
73.6% → 76.5% lines, 85.6% → 92.9% functions, without gaining a test of its own. 253 uncovered lines were deleted from it (corRest#4). A rise can be dead code removed rather than behaviour newly tested, and the headline figure cannot tell you which — so the file now says that where the numbers are.

The correction that matters

Every earlier revision described the HA cache-sync paths as untested code "needing a MongoDB replica set — an environment the functest harness does not stand up".

The harness stands it up fine. corTestParams.sh probes isMaster.setName, and on a replica set ha_cache_sync.test is simply in the run set. This machine has run mongod --replSet rs0 since 2026-08-30, so those paths are 108/149 lines and 10/10 functions covered here — zero never-entered functions between haInit.c, haEventApply.c and mongocHaWatch.c.

What does not stand it up is our CI, which runs a standalone mongo:8.0 — and the nightly is what publishes the figure. The sentence was describing our own workflows while reading as a property of the broker.

It is now a section of its own, with what the gap costs the published number (−0.34 pp lines, −0.73 pp functions, −0.26 pp branches) and a sixth entry in the reproduction list. SEAMWARE/corLibs#6 is the other half of the fix.

The classification is redone, across all four repos

The file has been carrying "2732 lines in the libs have never been classified at all" as an open item since the measurement widened on 2026-09-01. Done now, for all 5393 uncovered lines:

• 154 lines — under 3% — are the fault-injection cases (DB failure, socket death, allocator returning NULL). The reflex answer, "it's all unreachable error handling", is not what the data says.
• The largest group is ordinary behaviour nobody tested, and it is now named with counts from this run rather than described in the abstract: batch success/errors assembly (64), idPattern handling (23), @context LRU eviction and volatile expiry (14 and 10), $minDistance (4), expiresAt on a CSR subscription (4).
• The never-entered bucket needs no heuristic and is exact: 59 functions, 527 lines, grouped into shutdown/cleanup (136), parked-or-uncalled (94), httpEndpointDetect (42), null-object defaults (9) and 246 lines of genuinely untested behaviour.

The old hand-sampled percentages are removed rather than carried forward behind a warning — they measured a denominator that no longer exists.

▶ One thing worth acting on separately

ldDatasetIdDedup and its four helpers — 43 lines — are declared in corNgsild's public header and named in its README as part of the entity API, and are called from nowhere in the four repositories. That is the same shape as the corRest client layer just deleted: advertised library surface with no consumer. Wire it up or delete it.

(The other half of the parked group, ringSelfIntersects and its four helpers, 51 lines, is deliberately parked with the reason written at the call site. Not the same thing.)

🤖 Generated with Claude Code

https://claude.ai/code/session_01TGatXwrHx1CreL49sCuS37

[read-the-docs-community]

Documentation build overview

📚 coraine | 🛠️ Build #34350472 | 📁 Comparing 5108d28 against latest (e0a5427)

  🔍 Preview build  

1 file changed

± coverage.html