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

Per-folder event subscriptions deliver a moved alarm's events to the old owner during the authority/rebuild window #826

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

Residual from #808 (review finding 5). Server-object (i=2253) delivery is decided per condition and is strict, but MonitoredItems on an equipment folder receive events via SDK notifiers without a per-event ACL check, so after a deploy moves an alarm (or equipment) the old folder's subscribers still get its events (incl. EventId) until the rebuild lands — indefinitely after a failed apply. Commands are denied. Same for a native alarm still wired to a folder after a not-yet-applied surgical reference removal.

Minor related edge (narrows only): an Area named exactly like an equipment's opaque id makes that equipment's reference variables lose their Tag-grant match.

Residual from #808 (review finding 5). Server-object (i=2253) delivery is decided per condition and is strict, but MonitoredItems on an equipment folder receive events via SDK notifiers without a per-event ACL check, so after a deploy moves an alarm (or equipment) the old folder's subscribers still get its events (incl. EventId) until the rebuild lands — indefinitely after a failed apply. Commands are denied. Same for a native alarm still wired to a folder after a not-yet-applied surgical reference removal. Minor related edge (narrows only): an Area named exactly like an equipment's opaque id makes that equipment's reference variables lose their Tag-grant match.
dohertj2 added the type:bugpriority:p3 labels 2026-11-11 00:05:59 -05:00
dohertj2 commented 2026-11-11 05:24:32 -05:00
Author
Owner
Copy Link
Copy Source

Fixed (commits 8e1e73f9, 489664d1). Pushed to master in d1b6cad2. Folder event items decide per event on the live condition instance; a reference removal/move invalidates the folder's verdict cache (via the SDK's private MonitoredNode2.InvalidatePermissionCaches, guarded by a test). Live gate: with ACL on, A's folder received only A's alarm; after the reference removal events stopped. Residuals tracked in #838.

Fixed (commits `8e1e73f9`, `489664d1`). Pushed to master in `d1b6cad2`. Folder event items decide per event on the live condition instance; a reference removal/move invalidates the folder's verdict cache (via the SDK's private `MonitoredNode2.InvalidatePermissionCaches`, guarded by a test). Live gate: with ACL on, A's folder received only A's alarm; after the reference removal events stopped. Residuals tracked in #838.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
auto-managed
queue management
 blocked
Blocked by dependency or external hold
 cross-driver
queue management
 cross-repo
Needs coordinated change in another family repo (wire contract etc.)
 driver/abcip
queue management
 driver/ablegacy
queue management
 driver/focas
queue management
 driver/mqtt
MQTT / Sparkplug B broker-subscribe driver
 driver/opcuaclient
queue management
 driver/s7
queue management
 driver/twincat
queue management
 migrated
Migrated from a markdown backlog (2026-11 standardization)
 phase/1
queue management
 phase/2
queue management
 phase/3
queue management
 phase/4
queue management
 phase/5
queue management
 phase/6
queue management
 priority:p0
Must-have / blocking
 priority:p1
High priority
 priority:p2
Normal priority
 priority:p3
Low priority / nice to have
 queue/blocked
queue management
 queue/done
queue management
 queue/failed
queue management
 queue/in-progress
queue management
 queue/queued
queue management
 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 priority:p3 type:bug
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/lmxopcua#826
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?