The old probe did a subscribe-read-unsubscribe cycle every 5 seconds to
check connection health. This created unnecessary churn and didn't detect
the failure mode where long-lived subscriptions silently stop receiving
COM callbacks (e.g. stalled STA message pump). The new approach keeps a
persistent subscription on the health check tag and forces reconnect if
no value update arrives within a configurable threshold (ProbeStaleThresholdMs,
default 5s). Also adds STA message pump debug logging (5-min heartbeat with
message counters) and fixes log file path resolution for Windows services.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
SubscriptionManager.Subscribe was fire-and-forgetting the MxAccess COM
subscription creation. The initial OnDataChange callback could fire
before the subscription was established, losing the first (and possibly
only) value update. Changed to async SubscribeAsync that awaits
CreateMxAccessSubscriptionsAsync before returning the channel reader.
Subscribe_ReceivesUpdates now passes 5/5 consecutive runs.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Three fixes for the SubscriptionManager/MxAccessClient subscription pipeline:
1. Serialize Subscribe and UnsubscribeClient with a SemaphoreSlim gate to prevent
race where old-session unsubscribe removes new-session COM subscriptions.
CreateMxAccessSubscriptionsAsync is now awaited instead of fire-and-forget.
2. Fix dual VTQ delivery in MxAccessClient.OnDataChange — each update was delivered
twice (once via stored callback, once via OnTagValueChanged property). Now uses
stored callback as the single delivery path.
3. Store pending tag addresses when CreateMxAccessSubscriptionsAsync fails (MxAccess
down) and retry them on reconnect via NotifyReconnection/RetryPendingSubscriptionsAsync.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
