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

OPC UA ConditionRefresh on equipment/device folder subscriptions can still be followed by older deferred events #855

New Issue
Closed
opened 2026-11-11 07:55:31 -05:00 by dohertj2 · 2 comments
dohertj2 commented 2026-11-11 07:55:31 -05:00
Owner
Copy Link
Copy Source

Residual from #854. Server-object (i=2253) subscriptions are fixed (sequence cut + per-item replay, ConditionRefreshDeferralWireTests). Folder (notifier) subscriptions keep the old behaviour under overload: up to 4096 events already accepted by the SDK's MonitoredNode2 channel, and the SDK's per-(item, event type, source) verdict cache leaves no per-event, per-subscription decision point. Events stay in per-condition order with the newest last, so clients converge. Revisit if a folder-subscribing consumer is affected; options need SDK changes or our own per-item delivery for folder items. Documented in docs/security.md.

Residual from #854. Server-object (`i=2253`) subscriptions are fixed (sequence cut + per-item replay, `ConditionRefreshDeferralWireTests`). Folder (notifier) subscriptions keep the old behaviour under overload: up to 4096 events already accepted by the SDK's `MonitoredNode2` channel, and the SDK's per-(item, event type, source) verdict cache leaves no per-event, per-subscription decision point. Events stay in per-condition order with the newest last, so clients converge. Revisit if a folder-subscribing consumer is affected; options need SDK changes or our own per-item delivery for folder items. Documented in docs/security.md.
dohertj2 added the type:followuppriority:p3 labels 2026-11-11 07:55:31 -05:00
dohertj2 commented 2026-11-11 11:47:54 -05:00
Author
Owner
Copy Link
Copy Source

Owner decision 2026-11-11: build per-item delivery for folder (notifier) event subscriptions, so that ConditionRefresh on folder items gets the same sequence-cut guarantee as the Server object. This is event-path work and needs repeated independent review.

Owner decision 2026-11-11: **build per-item delivery** for folder (notifier) event subscriptions, so that ConditionRefresh on folder items gets the same sequence-cut guarantee as the Server object. This is event-path work and needs repeated independent review.
dohertj2 commented 2026-11-11 14:53:53 -05:00
Author
Owner
Copy Link
Copy Source

Done. Folder event items get per-item delivery with the same ConditionRefresh cut, per-event ACL and liveness checks as the Server object. Four review rounds. A shared per-report projection then brought the Lock hold at N=50 stalled items down to p50 81–181 µs (the first version measured 0.4–1.6 ms). The large-N / large-queue residual is #870. Pushed to master in e857135e..7a27ef1f; full suite green (20 projects, 0 failures, 0 warnings).

Done. Folder event items get per-item delivery with the same ConditionRefresh cut, per-event ACL and liveness checks as the Server object. Four review rounds. A shared per-report projection then brought the Lock hold at N=50 stalled items down to p50 81–181 µs (the first version measured 0.4–1.6 ms). The large-N / large-queue residual is #870. Pushed to master in `e857135e..7a27ef1f`; full suite green (20 projects, 0 failures, 0 warnings).
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: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/lmxopcua#855
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?