test(grpc): expand client.cpp error-branch coverage using Phase 2 substrate (round 2)

[kcenon]

What

Round 2 of protocols/grpc/client.cpp test coverage expansion using the Phase 2 substrate (frame_injector + mock_grpc_server_peer) merged in PR #1105 (Part of #1074). Round 1 sub-issues #994 and #1063 closed but the file still stands at 22.6% line / 9.5% branch in the 2026-05-06 coverage measurement (run 25430202846).

Why

grpc/client.cpp is the second-largest single-file contributor to the #953 coverage gap:

• Line gap: 482 LOC * (60% - 22.6%) = ~180 additional hit lines
• Branch gap: 926 branches * (35% - 9.5%) = ~236 additional hit branches

Phase 2 substrate (#1074) provides a mock_grpc_server_peer whose per-frame writes are routed through frame_injector, enabling deterministic error-path coverage on the gRPC client.

Where

Path	Role
src/protocols/grpc/client.cpp	File under test (482 LOC, 926 branches)
tests/unit/grpc_client_branch_test.cpp	Add new TEST_F cases
tests/support/mock_grpc_server_peer.h	Phase 2B/2E substrate
tests/support/frame_injector.h	Phase 2E fault-injection hook

How

Acceptance criteria

• grpc/client.cpp line coverage >= 60.0% (current 22.6%, +37.4pp)
• grpc/client.cpp branch coverage >= 35.0% (current 9.5%, +25.5pp)
• At least 5 new TEST_F cases driving previously-unreachable error branches via frame_injector:
  • connect timeout via injection_mode::drop on server SETTINGS
  • malformed SETTINGS-ACK via injection_mode::malform (flip type byte)
  • truncated response HEADERS via injection_mode::truncate
  • non-OK gRPC-Status trailer dispatched (drives client error-handling branches)
  • slow-write of DATA frame via injection_mode::slow_write
• No src/ changes; test-only PR

Test plan for reviewers

cmake --build build --target network_grpc_client_branch_test -j 4
./build/bin/network_grpc_client_branch_test
# Expect: all TEST_F PASS

Out of scope

• gRPC frame parsing (protocols/grpc/frame.cpp already at 95.8%)
• gRPC server (protocols/grpc/server.cpp already at 85.4%)
• Service registry (protocols/grpc/service_registry.cpp already at 84.3%)

Related

• Parent epic: Part of Expand unit test coverage from 40% to 80% #953
• Substrate provider: Part of infra(test): protocol-aware loopback peers + error injection (Phase 2 of #1060) #1074 (Phase 2E PR test(support): add frame_injector for protocol-aware fault injection (Phase 2E of #1074) #1105)
• Round 1 closed without hitting target: test: expand coverage for src/protocols/grpc/client.cpp #994, test(grpc): expand client.cpp coverage to 80% line / 70% branch #1063

[kcenon]

Round-2 status update: blocked on #1112 (structural fix)

This issue tracks Round-2 expansion of protocols/grpc/client.cpp error-branch coverage using the Phase 2 substrate (frame_injector + mock_grpc_server_peer). The same root cause that PR #1111 diagnosed for http2_client.cpp applies here: tests/support/mock_grpc_server_peer extends mock_h2_server_peer, so the gRPC error-branch tests share the same hermetic_transport_fixture and the same fixture-wide wait_for(3s) SETTINGS-handshake budget. Under coverage instrumentation that budget is exceeded (5.1-5.4s observed), so all instrumented GrpcClientHermeticTransport* TEST_F never reach the dispatcher branches they were authored to cover.

Sub-issue #1112 (infra(test): add COVERAGE_TIMEOUT_MULTIPLIER for hermetic_transport_fixture wait_for) is the Round-5 structural fix tracking this and remains OPEN with no PR yet. Sister issue #1106 (the http2_client twin) was skipped on the same grounds: see #1106 (comment).

Decision for this round: SKIP further Round-2 TEST_F expansion under #1107 until #1112 merges and its post-merge coverage workflow run on develop verifies the gate delta >= +20pp line AND >= +10pp branch on src/protocols/grpc/client.cpp against the current baseline (22.6% line, 9.5% branch from coverage run 25430202846). Adding new Round-2 TEST_F before #1112 lands would repeat the same 0pp-delta trap that Rounds 1/2/3 of #1106 produced.

Resumption criteria once #1112 is merged:

• Coverage workflow on develop reports +20pp line AND +10pp branch on src/protocols/grpc/client.cpp at the post-infra(test): add COVERAGE_TIMEOUT_MULTIPLIER for hermetic_transport_fixture wait_for (Round 5, Part of #1106, #953) #1112 sha.
• The instrumented GrpcClientHermeticTransportCoverageTest.CallRawSendsGrpcTimeoutHeaderWhenDeadlineSet and any sibling positive-path tests PASS under coverage instrumentation.

If #1112 lands but the gate is not cleared on this file, the diagnosis must be reopened before any new TEST_F are added to this issue.

[kcenon]

Resumption gate update: blocker is now #1115 (Round 6), not #1112

Round-5 multiplier approach (#1112 + PR #1113 + PR #1114) was verified to produce 0pp coverage delta on src/protocols/http2/http2_client.cpp despite the multiplier being applied correctly (15.175 s observed = wait_for(3s) × 5). SETTINGS handshake under coverage instrumentation now exceeds 15 s, and Test #5869 hit the 300 s ctest timeout — proving the multiplier-scaling approach is structurally bounded.

Architectural pivot: #1115 (infra(test): pivot to friend-injected process_frame for hermetic dispatcher coverage) is now the unblocker. Acceptance gate is unchanged: post-merge develop coverage workflow run measuring ≥+20pp line / ≥+10pp branch delta on http2_client.cpp versus the PR #1109 baseline (108/576 line, 97/979 branch).

Reference: PR #1114 merge, Coverage Analysis run 25562347620, and the FAIL diagnosis comment on #1112.