fix(deploy): a node with a ConfigDb records its degraded apply on its own NodeDeploymentState row (#601 review)

The apply writes the node's row Applied/null before the address-space outcome
is known; central adds the reason only when it ACCEPTS the ack, so a discarded
(stale/timed-out) ack left a fused node's row reading clean. The prefix moves
to ApplyAck.DegradedReasonPrefix so both writers spell the row identically.

Claude-Session: https://claude.ai/code/session_01Ef2ozxS7QPanGT8uoATbTe
This commit is contained in:
Joseph Doherty
2026-10-08 17:46:18 -04:00
parent fe7603ec6e
commit 345f40550b
4 changed files with 42 additions and 2 deletions
@@ -93,7 +93,7 @@ public sealed class ConfigPublishCoordinator : ReceiveActor, IWithTimers
/// degraded node DID apply the revision, so its status stays <see cref="NodeDeploymentStatus.Applied"/>
/// and the degradation rides the existing reason column, which <c>/fleet</c> already renders.
/// </summary>
public const string DegradedReasonPrefix = "Applied degraded: ";
public const string DegradedReasonPrefix = ApplyAck.DegradedReasonPrefix;
/// <summary>
/// Gitea #601 — whether a <c>NodeDeploymentState</c> row records a degraded apply: status
@@ -2588,6 +2588,11 @@ public sealed class DriverHostActor : ReceiveActor, IWithTimers, IWithUnboundedS
if (degraded)
{
// #601 review — the apply wrote this node's own row Applied/null before the outcome was known. Central
// adds the reason from the ack only when it ACCEPTS the ack (a timed-out or superseded deployment's ack
// is discarded), so a node with a ConfigDb records it itself; a driver-only node no-ops here.
UpsertNodeDeploymentState(pending.DeploymentId, NodeDeploymentStatus.Applied,
ApplyAck.DegradedReasonPrefix + (reason ?? "address-space apply degraded"));
OtOpcUaTelemetry.DeploymentApplied.Add(1, new KeyValuePair<string, object?>("outcome", "degraded"));
_log.Warning(
"DriverHost {Node}: deployment {Id} (rev {Rev}) applied DEGRADED — {Reason}. Acking Applied+degraded; re-dispatching the same revision re-applies it",