docs(plans): residual remediation plan — 7 remaining deferred items, one opus agent each
This commit is contained in:
Joseph Doherty
@@ -0,0 +1,140 @@
|
||||
# Residual Remediation Plan — the seven remaining deferred items
|
||||
|
||||
**Date:** 2026-08-15 · **Base:** `main` @ `f228ac22` · **Execution:** one opus subagent per item,
|
||||
parallel git worktrees, merged by the orchestrator in conflict-safe order, single rig
|
||||
redeploy + verification pass at the end.
|
||||
|
||||
Scope = the seven items left open after the arch-review remediation program closed residuals
|
||||
#1 (DCL counter drift, `491df111`) and #7 (target-scale load test, `40eff637`). Sources:
|
||||
residuals register in `2026-08-15-arch-review-remediation-execution-log.md` and deferred-work
|
||||
register rows.
|
||||
|
||||
## Execution rules (all agents)
|
||||
|
||||
- Verify worktree base is `f228ac22` or a descendant before starting; branch names below.
|
||||
- **Do NOT edit** `docs/plans/2026-07-08-deferred-work-register.md` or the execution-log
|
||||
residuals register — 7 parallel editors of one file guarantees conflicts. Report closure
|
||||
text + any **candidate new register rows** in the final report; the orchestrator records
|
||||
them centrally.
|
||||
- **Rig ownership:** only R6 (Playwright) may touch the `docker/` rig. R1/R2 are code+tests
|
||||
only; the orchestrator does one consolidated `bash docker/deploy.sh` + live probe after all
|
||||
merges.
|
||||
- Component docs / CLAUDE.md updates travel with the change per repo rules. No pushes anywhere.
|
||||
- Build `dotnet build ZB.MOM.WW.ScadaBridge.slnx` clean; run the tests your change touches.
|
||||
|
||||
## R1 — Per-table `needs_snapshot` in LocalDb (cross-repo) — branch `localdb-per-table-snapshot`
|
||||
|
||||
**Problem:** baselining one table (`RegisterReplicated(..., baselineExistingRows: true)`) sets a
|
||||
global `needs_snapshot`, so enabling replication for one new table re-streams every registered
|
||||
table in both directions.
|
||||
|
||||
**Approach:** in `~/Desktop/scadaproj/ZB.MOM.WW.LocalDb` (branch off its `main` @ `f627cee`):
|
||||
move the flag per-table (bookkeeping schema v3, upgraded in place on open, like v1→v2 was).
|
||||
Snapshot phase streams only flagged tables. Wire compatibility is the hard constraint: extend
|
||||
the snapshot negotiation **additively** (absent per-table scoping field ⇒ full snapshot, so
|
||||
0.1.x/0.2.x peers keep syncing). Crash safety: a table's flag clears only after *that table's*
|
||||
snapshot is acked. Version per library convention (schema change, wire-compatible ⇒ 0.3.0).
|
||||
Update the library README + `RegisterReplicated` remarks (which name this as the follow-up).
|
||||
Publish to the Gitea feed via `build/push.sh` only after the library suite is green. Then, in
|
||||
the ScadaBridge worktree: bump `Directory.Packages.props`, build, run the LocalDb-touching
|
||||
suites, update the CLAUDE.md LocalDb bullet + the umbrella `~/Desktop/scadaproj/CLAUDE.md`.
|
||||
|
||||
**Verify:** two-node integration test proving single-table baseline streams only that table;
|
||||
mixed-version interop test (old peer ⇒ full snapshot); ScadaBridge suite green on the bump.
|
||||
|
||||
## R2 — gRPC event batching — branch `grpc-event-batching`
|
||||
|
||||
**Problem:** every `AttributeValueChanged`/`AlarmStateChanged` rides one gRPC message; at target
|
||||
scale that is 37.5k messages/s/site of per-message overhead.
|
||||
|
||||
**Approach:** additive wire shape in the vendored proto (`Communication/SiteStreamGrpc/`,
|
||||
manual toggle-build-copy-untoggle regeneration; field numbers never reused): a batch message
|
||||
(repeated events) exposed via a **new** RPC or additive field so old peers are untouched —
|
||||
new-central↔old-site and old-central↔new-site must both keep working on the existing path.
|
||||
Server coalesces per subscriber under a small bounded window (size + time cap, e.g. ≤100
|
||||
events / ≤25 ms, configurable via options, validated); client unpacks and feeds the existing
|
||||
per-event pipeline so timestamps, generation fencing, reconnect-on-graceful-completion, and
|
||||
`IsLive` semantics are untouched. Batch-size histogram metric. Note interplay with register
|
||||
row 31: batching sits downstream of the shared publish stage and does not change the burst
|
||||
ceiling — say so in the component doc.
|
||||
|
||||
**Verify:** batcher unit tests (window/cap/flush-on-close), client/server round-trip
|
||||
integration, version-skew tests both directions, existing Communication suites green.
|
||||
No rig redeploy (orchestrator does it post-merge).
|
||||
|
||||
## R3 — Deployments page server-side paging + status counts — branch `deployments-server-paging`
|
||||
|
||||
**Problem:** the Central UI Deployments page client-materializes the full deployment list.
|
||||
|
||||
**Approach:** find the page's data path first; add a paged repository query (EF, following the
|
||||
repo's existing paged patterns — Audit Log keyset paging is the reference) plus a status-count
|
||||
aggregation query (counts by status computed server-side, one grouped query). Wire through
|
||||
whatever service layer the page uses; UI gets paging (pager or `Virtualize`, matching an
|
||||
existing page's idiom), 500 ms filter debounce, and status-count tiles. Bootstrap only, no
|
||||
third-party components; match the corporate UI conventions.
|
||||
|
||||
**Verify:** repository paging + count tests; existing CentralUI/ConfigurationDatabase suites
|
||||
green; page behavior exercised via whatever bUnit/unit seam exists for sibling pages.
|
||||
|
||||
## R4 — OtOpcUa LocalDb pin bump — branch (in `~/Desktop/OtOpcUa`) `localdb-bump`
|
||||
|
||||
**Problem:** OtOpcUa pins LocalDb 0.1.3 — supported skew, but drifting further as LocalDb moves.
|
||||
|
||||
**Approach:** bump to the newest LocalDb on the Gitea feed (0.2.1 now; if R1's 0.3.0 lands on
|
||||
the feed before you finish, take that instead). Reconcile API deltas (0.2.x added
|
||||
`DeregisterReplicated`, `MaxBatchBytes`, `baselineExistingRows`; check what OtOpcUa's usage
|
||||
touches). Build + full OtOpcUa test suite. Update its own docs/CLAUDE.md where the pin is
|
||||
recorded, and the umbrella `~/Desktop/scadaproj/CLAUDE.md` if it records the skew.
|
||||
|
||||
**Verify:** OtOpcUa builds clean, full suite green. No push.
|
||||
|
||||
## R5 — SandboxTests timing pin + flake-pattern sweep — branch `sandbox-timing-fix`
|
||||
|
||||
**Problem:** a fragile timing pin in the SandboxTests (noted pre-existing during the
|
||||
remediation program); the AwaitAssert-then-bare-assert flake class it belongs to had 3 other
|
||||
instances root-caused and fixed (`c4caebe9`, `cfa6acbf`).
|
||||
|
||||
**Approach:** locate the pin, root-cause it causally (delay-injection reproduction + negative
|
||||
control, same discipline as the prior flake fixes), replace the timing assumption with
|
||||
deterministic synchronization — test-side only unless the product is genuinely wrong. Then do
|
||||
the deferred **bounded sweep**: grep the test suites for the same pattern (AwaitAssert on one
|
||||
observable followed by a bare assert on a strictly-later observable), fix what's clearly the
|
||||
same class, list anything ambiguous as candidate register rows instead of guessing.
|
||||
|
||||
**Verify:** fixed tests re-run ≥5× green; touched suites green; fail-before-fix demonstrated
|
||||
via injected delay.
|
||||
|
||||
## R6 — Playwright environment failures — branch `playwright-env-fixes` (owns the rig)
|
||||
|
||||
**Problem:** 14 Playwright failures present on `main` before the remediation branch,
|
||||
rig-state related, never triaged.
|
||||
|
||||
**Approach:** run the suite against the current rig for a fresh baseline; catalog and classify
|
||||
every failure (stale rig data assumption, timing, selector drift, genuine app bug). Fix causes
|
||||
at the right layer — test fixes, or rig seed-state fixes via the ScadaBridge CLI (preferred
|
||||
over DB edits). Rig redeploy allowed for this agent if needed. Anything irreducible or
|
||||
app-side gets a precise writeup as a candidate register row rather than a papered-over test.
|
||||
|
||||
**Verify:** clean full-suite re-run; report before/after failure counts with per-test root
|
||||
causes. A genuine app bug found here is a finding to report, not necessarily to fix.
|
||||
|
||||
## R7 — `site_events` purge oplog-visibility operator note — branch `site-events-purge-note`
|
||||
|
||||
**Problem:** WP3.2's sliced retention DELETE is CDC-captured on a replicated site (correct by
|
||||
design — no separate resync path), so a purge burst shows up in `LocalDbOplogBacklog`; an
|
||||
operator watching the gauge can misread it as a replication problem.
|
||||
|
||||
**Approach:** documentation + one log line, no behavior change: a note in
|
||||
`docs/deployment/topology-guide.md` and `Component-SiteEventLogging.md` (what the burst looks
|
||||
like, why it is expected, how it drains), plus an Information-level log when a purge on a
|
||||
replication-enabled node deletes rows ("N rows purged; transient oplog backlog expected").
|
||||
|
||||
**Verify:** build green; the purge path's existing tests still green; log line unit-covered if
|
||||
the purge path has a test seam.
|
||||
|
||||
## Merge & close-out (orchestrator)
|
||||
|
||||
Merge order: R5 → R7 → R4 (separate repo, no merge here) → R3 → R2 → R1 → R6. Then: record
|
||||
all closures + candidate rows in the registers, consolidated `bash docker/deploy.sh` + live
|
||||
probe (stream batching live check, replication convergence, site_events purge log line),
|
||||
full-solution build + test, hold push for the user.
|
||||
Reference in New Issue
Block a user