mirror of
https://github.com/OPCFoundation/UA-.NETStandard.git
synced 2026-10-24 11:01:55 +08:00
romanettandClaude Opus 5.5
4fd76c1ec6
Three reliability fixes found during the client GC investigation. ## 1. PublishWorkerCount lagged a running publish worker (flaky test) `SubscriptionTests.IntentionalDeletionDropsPublishDemandWithoutUnregisteringSubscriptionAsync(True)` failed once on Linux CI (run 39261903989): `PublishWorkerCount` was 0 although a publish was already in flight. **Cause.** The publish controller started new workers with `Task.Run` and only then updated `PublishWorkerCount`. A worker could issue its first publish before the controller got that far. **Proof.** A 200 ms delay between starting the workers and updating the count reproduces the CI assertion in both test cases. **Fix.** The controller now sets the count before it starts the workers. **Verification:** - The test passes with the delay still in place. - 30 of 30 loop runs passed. - Client.Tests (net10.0): 3282 passed. One unrelated test failed under machine load: `SessionBindingLiveTests.BoundRequestCannotDispatchWhileNativeReplacementIsPendingAsync`, a channel reconnect. It passes 5/5 on its own. - The net48 build of Opc.Ua.Client is clean. ## 2. ServerLoadHarness: "error: BadRequestInterrupted" at the end of a run The harness printed `error: [80840000] (BadRequestInterrupted)` lines that looked like warm-up failures. They are the requests still in flight when the workload is stopped. `ChannelAsyncOperation` reports a cancelled token as BadRequestInterrupted, not as `OperationCanceledException`. Every one of these errors had the stop token cancelled (instrumented run with read, browse and write workloads). This is not a product bug. The read/write loops now exit quietly in that case, and read, write and sub runs no longer print the errors. ## 3. CI: record certificate allocation stacks Opc.Ua.Sessions.Tests sometimes fails its assembly teardown with "Certificate leak detected: 1 instance(s)": - 4 jobs between 2026-10-12 and 2026-10-19, out of about 278 macOS net10.0 shard runs. - Never seen on Linux or Windows. - The runs already included the fix for the failed HTTPS listener open (#4775). It did not reproduce locally: one full tracked run and six tracked runs of the WSS/HTTPS/reverse-connect fixtures were all clean. The per-fixture attribution showed no unbalanced fixture, which suggests work that outlives its fixture. The CI test step now sets `OPCUA_CERTIFICATE_LEAK_TRACKING=1`, so the next occurrence reports the allocation stack and the owning fixture. Tracked handles are removed from the tracker on dispose, and the WSS/HTTPS fixtures ran no slower with tracking on. The leak itself is **not** fixed by this PR. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>