dac7e1885d
The connect path was the one capability call the resilience pipeline never saw, so a driver that could not connect contributed zero breaker input and the /hosts resilience panel read 'All targets healthy' against a dead endpoint. InitializeAsync now routes through the invoker as DriverCapability.Initialize, keyed on the driver-instance id. - No pipeline retry: the actor's RetryConnect timer is the retry loop (parser forces retryCount overrides to 0, same funnel as write-shaped). - Breaker threshold 2, not the Read-sized 5: the breaker samples 30 s and the reconnect timer fires every 10 s, so at most three attempts fit one window — threshold 5 could never open. Pinned by its own test. - An open breaker fast-fails into the same InitializeFailed path as a real connect failure; the 15 s break window costs at most one extra tick. The best-effort teardown ShutdownAsync stays unwrapped. - Companion fix: DriverCapabilityInvokerFactory.Create now invalidates the instance's tracker snapshots with its pipelines — a respawn during an outage discarded the only breaker whose OnClosed could clear the OPEN flag, stranding a false 'Breaker OPEN' chip forever. Live gate PASSED on docker-dev (image symbol-verified per container): rtu-gate against dead 10.100.0.35:5021 opened its Initialize breaker on both centrals with the red 'BREAKER OPEN' chip on /hosts; a socat 5021→5020 forwarder recovered it (both breakers closed within 1 s, panel back to 'All targets healthy'); healthy MAIN-modbus recorded zero breaker events. Full suite 50/50 green. Evidence: docs/plans/2026-08-07-adminui-followups-and-live-gates.md §7.
54 lines
2.7 KiB
C#
54 lines
2.7 KiB
C#
namespace ZB.MOM.WW.OtOpcUa.Core.Abstractions;
|
|
|
|
/// <summary>
|
|
/// Enumerates the driver-capability surface points guarded by Phase 6.1 resilience pipelines.
|
|
/// Each value corresponds to one method (or tightly-related method group) on the
|
|
/// <c>Core.Abstractions</c> capability interfaces (<see cref="IReadable"/>, <see cref="IWritable"/>,
|
|
/// <see cref="ITagDiscovery"/>, <see cref="ISubscribable"/>, <see cref="IHostConnectivityProbe"/>,
|
|
/// <see cref="IAlarmSource"/>, <see cref="IHistoryProvider"/>).
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// Per the per-capability retry policy in <c>docs/v2/plan.md</c>: Read / HistoryRead /
|
|
/// Discover / Probe / AlarmSubscribe auto-retry; <see cref="Write"/> does NOT retry unless the
|
|
/// tag-definition carries <see cref="WriteIdempotentAttribute"/>. Alarm-acknowledge is treated
|
|
/// as a write for retry semantics (an alarm-ack is not idempotent at the plant-floor acknowledgement
|
|
/// level even if the OPC UA spec permits re-issue).
|
|
/// </remarks>
|
|
public enum DriverCapability
|
|
{
|
|
/// <summary>Batch <see cref="IReadable.ReadAsync"/>. Retries by default.</summary>
|
|
Read,
|
|
|
|
/// <summary>Batch <see cref="IWritable.WriteAsync"/>. Does not retry unless tag is <see cref="WriteIdempotentAttribute">idempotent</see>.</summary>
|
|
Write,
|
|
|
|
/// <summary><see cref="ITagDiscovery.DiscoverAsync"/>. Retries by default.</summary>
|
|
Discover,
|
|
|
|
/// <summary><see cref="ISubscribable.SubscribeAsync"/> and unsubscribe. Retries by default.</summary>
|
|
Subscribe,
|
|
|
|
/// <summary><see cref="IHostConnectivityProbe"/> probe loop. Retries by default.</summary>
|
|
Probe,
|
|
|
|
/// <summary><see cref="IAlarmSource.SubscribeAlarmsAsync"/>. Retries by default.</summary>
|
|
AlarmSubscribe,
|
|
|
|
/// <summary><see cref="IAlarmSource.AcknowledgeAsync"/>. Does NOT retry — ack is a write-shaped operation.</summary>
|
|
AlarmAcknowledge,
|
|
|
|
/// <summary><see cref="IHistoryProvider"/> reads (Raw/Processed/AtTime/Events). Retries by default.</summary>
|
|
HistoryRead,
|
|
|
|
/// <summary>
|
|
/// <c>IDriver.InitializeAsync</c> — connection establishment (R2-10 T10 closure: without this,
|
|
/// a driver that cannot connect contributes zero breaker input and the resilience panel stays
|
|
/// quiet for the failure operators most care about). Does NOT retry — the
|
|
/// <c>DriverInstanceActor</c> reconnect timer is the retry loop, and pipeline-level retries
|
|
/// would stack inside each timer tick. The tier-default breaker threshold is deliberately low
|
|
/// (2): at the 10 s reconnect cadence at most three attempts fit the breaker's 30 s sampling
|
|
/// window, so a Read-sized threshold of 5 could never open on connect failures.
|
|
/// </summary>
|
|
Initialize,
|
|
}
|