Honor MachineConnectivityBehavior during health checks
Summary
Item 2 of the Machine Policy enforcement series. The machine policy's MachineConnectivityBehavior was stored + shown in the UI but never consumed — an unreachable agent always reported agent_unreachable regardless of the policy.
This wires it into the manual health-check result (the generic seam in MachineHealthCheckService, so all transports benefit identically):
-
MayBeOfflineAndCanBeSkipped→ an unreachable agent is the benignoffline_tolerated(for elastic / transient targets that legitimately scale to zero). -
ExpectedToBeOnline(default, and when no policy is assigned) → keeps the hardagent_unreachable.
This matches how Octopus splits the concern: the machine policy governs health-check tolerance only; deploy-time skip of unavailable/unhealthy targets is a separate project-level setting (next item).
Why non-breaking
- Default
ExpectedToBeOnline⇒ error code unchanged out of the box. -
offline_toleratedis a new additive wire literal (pinned in the integrity test); no existing literal renamed. - No schema / migration / interface changes. Logic is a pure
MachineConnectivityEvaluatorconsumed by the service. - No Octopus wording in code/literals.
Test plan
-
Unit — MachineConnectivityEvaluator(null / ExpectedToBeOnline / MayBeOffline / default-ctor). -
Unit — MachineHealthCheckService: probe-fails + ExpectedToBeOnline →agent_unreachable; probe-fails + MayBeOffline →offline_tolerated; existing no-policy probe-fails →agent_unreachableunchanged. -
Unit — offline_toleratedliteral pinned + lower-snake-case convention. -
Full solution build 0 errors; full unit sweep 5718 passed.
No integration tier: this is an in-service error-code resolution with no new persistence (mirrors the existing agent_unreachable unit coverage).