test(hosting): close long-tail package coverage gaps
Author: ReubenBondCreated Aug 27, 2026Updated Sep 2, 2026
Labelsarea-testingarea-hostingarea-diagnosticstest
Goal
Close coverage gaps in maintained packages which are individually smaller than the primary workstreams but collectively block the repository from exceeding 90%.
Coverage report: https://github.com/dotnet/orleans/runs/98679059570
Initial scope
Representative physical-source gaps include:
- Dashboard: roughly 540 uncovered lines and near 50% coverage.
- Connections security: roughly 230 uncovered lines and near 46% coverage.
- Hosting, diagnostics, observability, dependency injection, reminders, memory persistence, clustering providers, and serializer adapters have smaller but material gaps.
Dashboard.ServiceCollectionExtensions.csis near 18% coverage.- TLS/duplex-pipe failure paths, dashboard service registration/options, metrics/diagnostic events, and hosting configuration branches are under-covered.
Work
- Produce a package-by-package table of covered/valid lines and branches after the larger area issues land.
- Prioritize packages below 80%, then close remaining gaps needed to exceed the repository goal.
- Add dashboard registration, options, authorization, routing, and failure-path tests.
- Add connection-security handshake, stream contract, cancellation, certificate, and error-path tests.
- Cover diagnostics/metrics emission and disabled/configured behavior.
- Cover hosting and dependency-injection validation, named options, duplicate registration, and configuration failures.
- Cover small reminder, persistence, clustering, and serializer-adapter branches using existing fixtures.
- Split implementation PRs by package/owner while tracking them in this issue.
Acceptance criteria
- Every maintained package is at least 90% line coverage, or has an evidence-backed exception tracked in the dead-code/reachability audit.
- No package below 80% remains unassigned.
- Tests assert runtime and configuration outcomes rather than only resolving services.
- Generated files, reference API surfaces, and platform-specific code are treated consistently by the canonical coverage model.
Source: dotnet/orleans