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

FOCAS/AbLegacy InitializeAsync orphans previous DeviceState loops when called without teardown #630

New Issue
Closed
opened 2026-10-08 09:21:56 -04:00 by dohertj2 · 1 comment
dohertj2 commented 2026-10-08 09:21:56 -04:00
Owner
Copy Link
Copy Source

Found by review R5 (#602). FocasDriver.InitializeAsync (:207) and AbLegacyDriver.InitializeAsync (:180) overwrite _devices[host] = new DeviceState(...) without cancelling, joining or disposing the old state's probe, recycle and fixed-tree loops (each holding a client). DriverInstanceActor.AdoptConfigDuringInit (~:831) calls InitializeAsync without teardownFirst, so an ApplyDelta that arrives mid-init orphans a full loop set that neither ShutdownAsync nor the new shutdown join (#602 STAB-23/6) can reach.

This is the dispose-before-overwrite rule from the comms-loss section of CLAUDE.md, which Modbus and MQTT already follow.

  • At the top of InitializeAsync in both drivers, cancel, bounded-join and dispose any existing _devices entries
  • Test: Initialize twice, assert the first state's loops have finished and its clients are disposed (with a positive control that the loops were running)
  • Check the same pattern in the other poll drivers

Filed 2026-10-08 by the hardware-available issue sweep.

Found by review R5 (#602). `FocasDriver.InitializeAsync` (~:207) and `AbLegacyDriver.InitializeAsync` (~:180) overwrite `_devices[host] = new DeviceState(...)` without cancelling, joining or disposing the old state's probe, recycle and fixed-tree loops (each holding a client). `DriverInstanceActor.AdoptConfigDuringInit` (~:831) calls `InitializeAsync` without `teardownFirst`, so an ApplyDelta that arrives mid-init orphans a full loop set that neither `ShutdownAsync` nor the new shutdown join (#602 STAB-23/6) can reach. This is the dispose-before-overwrite rule from the comms-loss section of CLAUDE.md, which Modbus and MQTT already follow. - [ ] At the top of `InitializeAsync` in both drivers, cancel, bounded-join and dispose any existing `_devices` entries - [ ] Test: Initialize twice, assert the first state's loops have finished and its clients are disposed (with a positive control that the loops were running) - [ ] Check the same pattern in the other poll drivers *Filed 2026-10-08 by the hardware-available issue sweep.*
dohertj2 commented 2026-10-08 16:34:05 -04:00
Author
Owner
Copy Link
Copy Source

Fixed in 2377da3c (Merge b626-630): FOCAS, AbLegacy, AbCip, TwinCAT, S7 and OpcUaClient InitializeAsync now release prior device/session state (cancel, bounded join, dispose) before re-initialising.

Fixed in 2377da3c (Merge b626-630): FOCAS, AbLegacy, AbCip, TwinCAT, S7 and OpcUaClient InitializeAsync now release prior device/session state (cancel, bounded join, dispose) before re-initialising.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
auto-managed
queue management
 cross-driver
queue management
 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
 phase/1
queue management
 phase/2
queue management
 phase/3
queue management
 phase/4
queue management
 phase/5
queue management
 phase/6
queue management
 queue/blocked
queue management
 queue/done
queue management
 queue/failed
queue management
 queue/in-progress
queue management
 queue/queued
queue management
No Label
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#630
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?