From 689fc06e853026d72ac781231ed02c55260abf83 Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Tue, 21 Jul 2026 03:27:54 -0400 Subject: [PATCH] docs(486): live-gate the failed-apply fix on docker-dev MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Regression check first, since this changes ACK semantics: a normal deploy still records Applied on all six nodes. Then the same induction as #485 — the node now records Failed with a reason while the five nodes that read the real artifact record Applied (pre-fix all six claimed Applied), and the log shows it staying on the PREVIOUS revision rather than the dispatched one, which is what lets a retry land. Values kept flowing throughout (59603, current), and the next real deploy applied normally. Claude-Session: https://claude.ai/code/session_01GASWkNEi68FSCtvr6rLoEW --- docs/plans/2026-07-21-issue-485-live-gate.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/plans/2026-07-21-issue-485-live-gate.md b/docs/plans/2026-07-21-issue-485-live-gate.md index 34d98729..e766a389 100644 --- a/docs/plans/2026-07-21-issue-485-live-gate.md +++ b/docs/plans/2026-07-21-issue-485-live-gate.md @@ -61,3 +61,16 @@ not a data-plane one: the node keeps serving its last good configuration through ACK `Failed` and leave `_currentRevision` alone when the artifact could not be read, so the normal deploy retry heals it. Tracked separately rather than folded in here, because it changes deploy ACK semantics fleet-wide. + +## Addendum — issue #486 fix, live-gated (2026-07-21) + +The finding above is now fixed (`DriverHostActor.ApplyAndAck` fails the apply when `ReconcileDrivers` +returns null) and gated on the same rig with the same induction. + +| # | Check | Result | Evidence | +|---|---|---|---| +| 8 | Regression — a normal deploy still ACKs Applied fleet-wide | ✅ | The change alters ACK semantics, so this is the risk that matters. A genuine deploy recorded `Status = Applied` on **all six** nodes. | +| 9 | An unreadable artifact now ACKs Failed, with a reason | ✅ | central-2 recorded `Status = Failed` + `the deployment artifact could not be read (ConfigDb unreachable, or the row is missing/empty); nothing was applied`. The five nodes that read the real artifact recorded Applied — so the fleet view now distinguishes them. Pre-fix, all six claimed Applied. | +| 10 | The revision is NOT advanced | ✅ | `apply of a855dd9e… FAILED — … Staying on revision 5bc0d9f3…` — the **previous** revision, not the dispatched `583122b7…`. This is what stops `HandleDispatchFromSteady` from short-circuiting a retry of that revision. | +| 11 | The node keeps serving throughout (#485 still holds) | ✅ | The #485 guard fired first (`keeping the 5 running driver(s)`), and `ns=2;s=pymodbus/plc/HR200X` read **59603 @ 07:27:28**, live and current, after the Failed apply. Failing the apply reports the truth; it does not tear anything down. | +| 12 | The node recovers on the next real deploy | ✅ | The following deployment applied on central-2 (`children=5`) and recorded Applied on all six nodes. |