Files
UA-.NETStandard/.github/scripts
romanett b8f07843b2 Secure channel: never answer with an expired token; accept a just-expired one (+ labelled soak/stress CI) (#4698)
## Summary

**Secure channel: a client could drop the channel when the server
answered with a just-expired token.** Running the long-dormant
ConnectionStability soak locally, the subscription channel shut down
with `BadSecureChannelClosed`. The session then timed out and the
subscription was abandoned. Root cause, against OPC 10000-4 §5.6.2.1:

1. **Server (rule 2: use the old token only "until the SecurityToken
expires").** After a renew, the server keeps securing messages with the
old token until the client sends something secured with the new one.
That activation only happened on *receive*. A client that sends nothing,
for example one whose Publish requests are all outstanding, kept getting
responses secured with the old token after it expired.
2. **Client (rule 3: "accept Messages secured by an expired
SecurityToken for up to 25 % of the token lifetime").** The client
rejected any such response the moment the token expired, throwing
`BadTcpSecureChannelUnknown`, and shut the channel down.

From the failing run (token lifetime 10 s): the client renewed to token
#11 at 09:59:01.686 and sent nothing on that channel afterwards. The
server, still on #10, sent a Publish response at 09:59:04.389, 380 ms
after #10 expired. The client rejected it and closed the channel.
Nothing reconnected, the 10 s session timeout expired, and the server
abandoned the subscription.

Both halves date back to the 2016 initial commit; this is not a recent
regression. It hits whenever the client sends nothing on the channel
between renewing and the old token's expiry, so it is timing-dependent.

### Fix
- `UaSCBinaryChannel.ActivateRenewedTokenIfDue()` activates a pending
renewed token once the current one passes `TokenActivationPeriod` (95
%). This is the rule the receive path already applied. It is now shared,
and `TcpServerChannel.SendResponse` calls it before securing a response.
- `ReadSymmetricMessage` accepts responses (not requests) secured with
an expired token for `TcpMessageLimits.TokenExpiryGracePeriod` (25 %) of
its lifetime.

### Tests
`TcpReconnectKeyAgreementTests` now runs the server channel and the peer
on one shared `FakeTimeProvider`:
- `ResponseSentAfterTheCurrentTokenExpiresUsesTheRenewedTokenAsync`: a
response sent at 96 % of the old token's lifetime is secured with the
renewed token.
-
`ResponseSecuredWithTheExpiredTokenIsAcceptedWithinTheGracePeriodAsync`:
accepted at 120 % of the lifetime, rejected at 130 %.

Both fail without the fix. All 40 tests in the fixture pass with it.

## CI: soak and stress runs on labelled PRs (and the soak that tested
nothing)

The bug stayed hidden because `stability-test.yml` still filtered
`Opc.Ua.Client.Tests` after #3810 moved the test to
`Opc.Ua.Sessions.Tests` (2026-05-28). Since then the nightly has run
**zero tests** while reporting green: runs dropped from ~100 min to ~15
min.

- `stability-test.yml` now targets `Opc.Ua.Sessions.Tests` and writes a
TRX file.
- New `.github/scripts/assert-tests-ran.ps1`, used by all three opt-in
workflows, fails a run in which no test executed, or none passed.
Contract-tested in `CiAssertTestsRanTests`.
- Like `interop`, the opt-in workflows can now run on a labelled PR.
They are not required checks. A later push cancels the run in progress,
and adding an unrelated label neither starts nor cancels a run.

| Label | Workflows | Run on a PR |
| --- | --- | --- |
| `stress` | Stress Tests (ChaosTCP) | Random seed, saved as
`chaos-seed.txt` in the results artifact |
| `soak` | Connection Stability Test, Sample HA Long-Haul Test | 30 min
stability; 15 min per HA scenario |

## Test plan

- [x] `TcpReconnectKeyAgreementTests`: 40/40 pass; the 2 new tests fail
without the fix
- [x] All `Opc.Ua.Core.Tests.Stack` tests (net10.0): 3548 passed, 0
failed
- [x] `CiAssertTestsRanTests`: 4/4
- [x] `soak` + `stress` labelled run on this PR (before the fix): both
stability tests, both HA long-haul scenarios and ChaosTCP passed on
Linux (the label triggers and push-cancellation work)
- [x] Local short-haul soak with the fix (Windows, 10 s tokens), 2 runs:
both pass with full notification counts; run 2 hit the window once
(`Token activated forced` on send) and kept the channel
- [x] `soak` + `stress` labelled run with the fix: Connection Stability
(2 tests), Sample HA Long-Haul and ChaosTCP all pass

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 19:14:25 +02:00
..