You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Raise coverage of src/protocols/quic/loss_detector.cpp from the pre-Step-1 snapshot level (line 7.6% of ~210 instrumented lines, 2026-04-13 run) to line >= 70% and branch >= 60%, measured under the updated coverage workflow (all BUILD_WITH_* flags, lcov --rc lcov_branch_coverage=1).
Re-measurement required at start of work. Numbers above are from the pre-Step-1 baseline (2026-04-13), captured before the coverage workflow was updated in #986, #987, #989. The current value on develop may differ. Run the coverage workflow (or local lcov) against HEAD before designing tests, and record the current baseline in the first comment on this issue.
The uncovered region concentrates in error and boundary paths — exactly the surfaces that regress during the ongoing Result<T> migration and API stabilization.
Bringing this file over the 70% line / 60% branch bar is a direct contribution to the Expand unit test coverage from 40% to 80% #953 acceptance criteria (80% line / 70% branch ecosystem-wide).
CMake wiring: the existing add_executable + gtest_discover_tests pattern in tests/unit/CMakeLists.txt.
How
Approach
Re-measure current coverage for this file against develop HEAD and record in an issue comment before writing tests.
Identify the uncovered branches and error paths using the lcov branch report.
Add unit tests that exercise:
Timer firing order under jitter, ACK eliciting vs non-eliciting packets, PTO computation with varying RTT, loss threshold crossing, persistent congestion detection
Keep tests hermetic — no network, no filesystem, no sleeps beyond a few ms for timer-driven code paths.
Run ASAN/TSAN/UBSAN locally (or rely on CI) before requesting review.
Acceptance Criteria
Current-baseline coverage for src/protocols/quic/loss_detector.cpp recorded as an issue comment
src/protocols/quic/loss_detector.cpp line coverage >= 70% on develop after merge
src/protocols/quic/loss_detector.cpp branch coverage >= 60% on develop after merge
All tests pass on Ubuntu/macOS/Windows CI
ASAN, TSAN, UBSAN sanitizer jobs green
No regressions in overall network_system coverage
Out of Scope
Refactoring src/protocols/quic/loss_detector.cpp beyond what is strictly needed to make paths testable (seam insertion is acceptable; behavior changes are not).
Integration or end-to-end tests — those live in separate files and are tracked elsewhere.
Part of #953
What
Raise coverage of
src/protocols/quic/loss_detector.cppfrom the pre-Step-1 snapshot level (line 7.6% of ~210 instrumented lines, 2026-04-13 run) to line >= 70% and branch >= 60%, measured under the updated coverage workflow (allBUILD_WITH_*flags,lcov --rc lcov_branch_coverage=1).Why
src/protocols/quic/loss_detector.cppsits among the lowest-coverage files in the network_system source tree per the Expand unit test coverage from 40% to 80% #953 audit.Where
src/protocols/quic/loss_detector.cpptests/unit/for an existing file that targets this translation unit; if none exists, create one following the naming convention used by already-closed siblings (e.g. test: expand coverage for src/protocols/quic/connection.cpp #990, test: expand coverage for src/protocols/http2/http2_client.cpp #991, test: expand coverage for src/protocols/http2/http2_server.cpp #992, test: expand coverage for src/protocols/quic/crypto.cpp #993, test: expand coverage for src/protocols/grpc/client.cpp #994).add_executable+gtest_discover_testspattern intests/unit/CMakeLists.txt.How
Approach
developHEAD and record in an issue comment before writing tests.Acceptance Criteria
src/protocols/quic/loss_detector.cpprecorded as an issue commentsrc/protocols/quic/loss_detector.cppline coverage >= 70% ondevelopafter mergesrc/protocols/quic/loss_detector.cppbranch coverage >= 60% ondevelopafter mergeOut of Scope
src/protocols/quic/loss_detector.cppbeyond what is strictly needed to make paths testable (seam insertion is acceptable; behavior changes are not).Dependencies