Skip to content

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 benign offline_tolerated (for elastic / transient targets that legitimately scale to zero).
  • ExpectedToBeOnline (default, and when no policy is assigned) → keeps the hard agent_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_tolerated is a new additive wire literal (pinned in the integrity test); no existing literal renamed.
  • No schema / migration / interface changes. Logic is a pure MachineConnectivityEvaluator consumed 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_unreachable unchanged.
  • Unit — offline_tolerated literal 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).

Merge request reports

Loading