#10865·orleans

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.cs is 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.