dohertj2/scadaproj
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

[LocalDb] Publish 0.3.7 and adopt in ScadaBridge + OtOpcUa (tombstone fix #16) #53

New Issue
Closed
opened 2026-11-09 22:32:00 -05:00 by dohertj2 · 1 comment
dohertj2 commented 2026-11-09 22:32:00 -05:00
Owner
Copy Link
Copy Source

LocalDb 0.3.7 (scadaproj be5e9fd, #16) fixes deleted-row resurrection when a peer is offline longer than TombstoneRetention. Source only; not published.

To adopt:

  • Owner publishes LocalDb 0.3.7 to the Gitea feed (along with the other unpublished 0.3.5/0.3.6 changes: sync endpoint ApiKey enforcement (#36), FK-ordered snapshots, PK upserts).
  • ScadaBridge: bump the 0.3.4 pin → 0.3.7 (a ScadaBridge issue gets filed when it's published). Note #36: set the same sync ApiKey on both site-pair nodes.
  • OtOpcUa: bump the 0.3.4 pin → 0.3.7 (lmxopcua issue at publish time). Same ApiKey note for the QA pair.
  • Deploy notes: pairs stop and start together; tombstone ledger growth while a peer is down (ScadaBridge sf_messages).
LocalDb `0.3.7` (scadaproj `be5e9fd`, #16) fixes deleted-row resurrection when a peer is offline longer than `TombstoneRetention`. Source only; **not published**. To adopt: - [ ] Owner publishes LocalDb 0.3.7 to the Gitea feed (along with the other unpublished 0.3.5/0.3.6 changes: sync endpoint `ApiKey` enforcement (#36), FK-ordered snapshots, PK upserts). - [ ] ScadaBridge: bump the `0.3.4` pin → 0.3.7 (a ScadaBridge issue gets filed when it's published). Note #36: set the same sync `ApiKey` on both site-pair nodes. - [ ] OtOpcUa: bump the `0.3.4` pin → 0.3.7 (lmxopcua issue at publish time). Same `ApiKey` note for the QA pair. - [ ] Deploy notes: pairs stop and start together; tombstone ledger growth while a peer is down (ScadaBridge `sf_messages`).
dohertj2 added the type:followuppriority:p2cross-repo labels 2026-11-09 22:32:00 -05:00
dohertj2 added the blocked label 2026-11-10 08:41:38 -05:00
dohertj2 commented 2026-11-12 14:08:38 -05:00
Author
Owner
Copy Link
Copy Source

Published ZB.MOM.WW.LocalDb 0.3.7 (all three packages) on 2026-11-12. Built from scadaproj 30a12dd in Release, 259/259 tests passing. Index commit: ccfcc7c. 0.3.7 includes the unpublished 0.3.5 (Sqlite 10.0.13) and 0.3.6 changes: sync ApiKey enforcement (#36), FK-ordered snapshots (#37), PK upserts (#38), the snapshot drift guard (#39), the AUTOINCREMENT refusal (#46) and snapshot dead-letter metrics (#50). It also includes the #16 tombstone fix.

Feed registration lists 0.3.7 for all three packages. The SHA256 of each downloaded copy matches the local nupkg:

Package SHA256
ZB.MOM.WW.LocalDb.0.3.7.nupkg 5ac1db336e9b71700cd253bfe986acc13d24d0286fcc38bb277317845c892321
ZB.MOM.WW.LocalDb.Contracts.0.3.7.nupkg 5e7a6fce04f415720f9a6aac7e21ca43d1e842f6a74282120ae8aae2a62eb824
ZB.MOM.WW.LocalDb.Replication.0.3.7.nupkg f579f1218ccc279836841c06e2989e8d0d67009866548eeea6e162d4eb45b07d

Adoption

  • ScadaBridge main @ 12fa7aff (ScadaBridge#130, closed): 11,188 tests passed with 0 failures, excluding Playwright, which needs a browser server on :3000.
  • OtOpcUa master @ e3031654 (lmxopcua#889, closed): 20,033 passed, 415 skipped, and 1 load flake that passes when re-run alone. Host.IntegrationTests passed 313 (the LocalDb pair harness).

Config: every replicated pair already had one identical key on both nodes: the ScadaBridge rig site-a pair and the OtOpcUa docker-dev site-a pair. The OtOpcUa compose key is now ${OTOPCUA_SITE_A_LOCALDB_SYNC_KEY:-…}, one variable shared by both nodes. Neither repo holds a QA template with a literal key; the runbooks prescribe ${secret:…} or an env var.

Deploy notes (added to both repos' runbooks; nothing is deployed, and vd03/vq03/vq04 still run 0.3.4 builds):

  1. Stop and start each replicated pair together. Rolling upgrades are unsupported.
  2. LocalDb:Replication:ApiKey must be byte-identical on both nodes. Both the library (since 0.3.6) and the host interceptor check it, and a mismatch stops convergence with Unauthenticated.
  3. As of 0.3.7, deleted rows no longer resurrect after a long outage. The cost is that the survivor's tombstone ledger grows while its peer is down: ScadaBridge sf_messages and site_events deletes, OtOpcUa deployment prunes and alarm_sf_events. The optional TombstoneHardCap bounds that growth at the price of the old risk.
  4. 0.3.6 refuses AUTOINCREMENT replicated keys. Neither app has any.

No live docker 2-node check was run: a lmxopcua#799 soak container was active, and both rigs were started by someone else, so I did not restart them. Replication coverage comes from the in-process real-gRPC pair harnesses in both suites.

**Published `ZB.MOM.WW.LocalDb` 0.3.7 (all three packages) on 2026-11-12.** Built from scadaproj `30a12dd` in Release, 259/259 tests passing. Index commit: `ccfcc7c`. 0.3.7 includes the unpublished 0.3.5 (Sqlite 10.0.13) and 0.3.6 changes: sync `ApiKey` enforcement (#36), FK-ordered snapshots (#37), PK upserts (#38), the snapshot drift guard (#39), the AUTOINCREMENT refusal (#46) and snapshot dead-letter metrics (#50). It also includes the #16 tombstone fix. Feed registration lists 0.3.7 for all three packages. The SHA256 of each downloaded copy matches the local nupkg: | Package | SHA256 | |---|---| | ZB.MOM.WW.LocalDb.0.3.7.nupkg | `5ac1db336e9b71700cd253bfe986acc13d24d0286fcc38bb277317845c892321` | | ZB.MOM.WW.LocalDb.Contracts.0.3.7.nupkg | `5e7a6fce04f415720f9a6aac7e21ca43d1e842f6a74282120ae8aae2a62eb824` | | ZB.MOM.WW.LocalDb.Replication.0.3.7.nupkg | `f579f1218ccc279836841c06e2989e8d0d67009866548eeea6e162d4eb45b07d` | **Adoption** - ScadaBridge `main` @ `12fa7aff` (ScadaBridge#130, closed): 11,188 tests passed with 0 failures, excluding Playwright, which needs a browser server on :3000. - OtOpcUa `master` @ `e3031654` (lmxopcua#889, closed): 20,033 passed, 415 skipped, and 1 load flake that passes when re-run alone. Host.IntegrationTests passed 313 (the LocalDb pair harness). **Config:** every replicated pair already had one identical key on both nodes: the ScadaBridge rig site-a pair and the OtOpcUa docker-dev site-a pair. The OtOpcUa compose key is now `${OTOPCUA_SITE_A_LOCALDB_SYNC_KEY:-…}`, one variable shared by both nodes. Neither repo holds a QA template with a literal key; the runbooks prescribe `${secret:…}` or an env var. **Deploy notes** (added to both repos' runbooks; nothing is deployed, and vd03/vq03/vq04 still run 0.3.4 builds): 1. Stop and start each replicated pair together. Rolling upgrades are unsupported. 2. `LocalDb:Replication:ApiKey` must be byte-identical on both nodes. Both the library (since 0.3.6) and the host interceptor check it, and a mismatch stops convergence with `Unauthenticated`. 3. As of 0.3.7, deleted rows no longer resurrect after a long outage. The cost is that the survivor's tombstone ledger grows while its peer is down: ScadaBridge `sf_messages` and `site_events` deletes, OtOpcUa deployment prunes and `alarm_sf_events`. The optional `TombstoneHardCap` bounds that growth at the price of the old risk. 4. 0.3.6 refuses `AUTOINCREMENT` replicated keys. Neither app has any. No live docker 2-node check was run: a lmxopcua#799 soak container was active, and both rigs were started by someone else, so I did not restart them. Replication coverage comes from the in-process real-gRPC pair harnesses in both suites.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocked
Blocked by dependency or external hold
 cross-repo
Needs coordinated change in another family repo (wire contract etc.)
 migrated
Migrated from a markdown backlog (2026-11 standardization)
 priority:p0
Must-have / blocking
 priority:p1
High priority
 priority:p2
Normal priority
 priority:p3
Low priority / nice to have
 type:bug
Defect in shipped behaviour
 type:debt
Technical debt / hygiene
 type:deploy-gate
Rollout/deploy/migration step not yet done on an environment
 type:docs
Documentation work
 type:feature
Feature implementation
 type:followup
Follow-up deferred from a plan, PR or gate
 type:infra
Infrastructure and scaffolding
 type:review-finding
Unfixed finding from an architecture/code review
 type:test
Test work
No Label blocked cross-repo priority:p2 type:followup
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dohertj2 (dohertj2)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dohertj2/scadaproj#53
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?