OpcUaClient integration: #816 host-name test (validate: null) intermittently fails BadRequestInterrupted on first secure connect #910

New Issue

2026-11-13T08:33:06-05:00

dohertj2 commented

2026-11-13 08:33:06 -05:00

Found during the #615 G2 full-suite run (2026-11-13, master 16ddddb2).

ServerHostNameValidationTests.Without_host_name_validation_a_trusted_certificate_for_another_host_connects(validate: null) failed twice in a row:

in the full solution run;
in the first standalone re-run of Driver.OpcUaClient.IntegrationTests.

Error: OPC UA Client failed to connect … opc.tcp://10.100.0.35:50000 -> BadRequestInterrupted (0x80840000), from OpcUaClientDriver.InitializeAsync (OpcUaClientDriver.cs:589).

It then passed 6 times in a row: 2× filtered, 1× the class alone, 3× the whole project. The validate: false case and the other two #816 tests never failed.

It happens on the first secure (Basic256Sha256 SignAndEncrypt) session against the shared opc-plc, with a freshly generated throwaway client certificate. The cause is not established: the fixture may have been under load from the rest of the run, or opc-plc may interrupt the first request from a new client certificate.

To do:

reproduce with --count-style repeats;
capture opc-plc's log at the failure;
if it is fixture-side, add a bounded retry around the first secure connect in the test (not in the driver).

Found during the #615 G2 full-suite run (2026-11-13, master `16ddddb2`). `ServerHostNameValidationTests.Without_host_name_validation_a_trusted_certificate_for_another_host_connects(validate: null)` failed twice in a row: 1. in the full solution run; 2. in the first standalone re-run of `Driver.OpcUaClient.IntegrationTests`. Error: `OPC UA Client failed to connect … opc.tcp://10.100.0.35:50000 -> BadRequestInterrupted (0x80840000)`, from `OpcUaClientDriver.InitializeAsync` (`OpcUaClientDriver.cs:589`). It then passed 6 times in a row: 2× filtered, 1× the class alone, 3× the whole project. The `validate: false` case and the other two #816 tests never failed. It happens on the first secure (Basic256Sha256 SignAndEncrypt) session against the shared opc-plc, with a freshly generated throwaway client certificate. The cause is not established: the fixture may have been under load from the rest of the run, or opc-plc may interrupt the first request from a new client certificate. To do: - reproduce with `--count`-style repeats; - capture opc-plc's log at the failure; - if it is fixture-side, add a bounded retry around the first secure connect in the test (not in the driver).

dohertj2 added the type:test priority:p3 labels 2026-11-13 08:33:06 -05:00

dohertj2 commented

2026-11-13 12:44:30 -05:00

Fixed in 73132b7d (merged 79371402). Cause: the driver's 3 s PerEndpointConnectTimeout, not opc-plc - opc-plc log at the G2 failure shows the client closing 48 ms after the secure channel was created, 3 s after endpoint discovery. validate:null failed only because it is the assembly's first test (cold-process crypto/cert cost). Test now uses a 15 s budget; driver now reports a TimeoutException naming PerEndpointConnectTimeout instead of BadRequestInterrupted. 35/35 whole-project runs green. Open: whether to raise the production default is a separate decision.

Fixed in 73132b7d (merged 79371402). Cause: the driver's 3 s PerEndpointConnectTimeout, not opc-plc - opc-plc log at the G2 failure shows the client closing 48 ms after the secure channel was created, 3 s after endpoint discovery. validate:null failed only because it is the assembly's first test (cold-process crypto/cert cost). Test now uses a 15 s budget; driver now reports a TimeoutException naming PerEndpointConnectTimeout instead of BadRequestInterrupted. 35/35 whole-project runs green. Open: whether to raise the production default is a separate decision.

dohertj2 referenced this issue from a commit

2026-11-13 12:44:31 -05:00

fix(opcuaclient): #910 name the per-endpoint connect budget; widen it in the #816 host-name tests

dohertj2 closed this issue

2026-11-13 12:44:37 -05:00

dohertj2 referenced this issue

2026-11-13 13:48:26 -05:00

OpcUaClient: decide whether the 3 s PerEndpointConnectTimeout default is too tight for a first secure connect #912

Sign in to join this conversation.