[romanett]

Description

Findings of a full CTT run (23 parts, 3,752 test cases, CTT 1.05.06 / scripts 1.05.513) against the merge of #4477, #4482, #4485 and #4486, which are all on master now, plus the CTT defects filed in Mantis.

No server code changes: the PR changes only the CTT configuration of the reference server sample and the plans/ documentation.

CTT configuration: raise ChannelLifetime to 120 s

CTT Security None 007.js and Security Basic256Sha256 005.js failed (also on master): they keep SecureChannels without a Session idle for about 51 s (60 s token, stretched by the CTT's CloseSession delay, C50) and expect the newest one to close with Good. TcpTransportListener.DetectInactiveChannels had already closed it after ChannelLifetime (30 s) without traffic (CloseSecureChannel().Result received BadInvalidState).

samples/Reference/ConsoleReferenceServer/Ctt.ReferenceServer.Config.xml now sets ChannelLifetime to 120000. The default of 30000 and the server's inactivity cleanup are unchanged.

An earlier revision of this PR changed the inactivity cleanup instead, keeping idle Session-less channels open until their token expired (Part 4 §5.6.2.1). That change was withdrawn because it lets an unauthenticated client hold a channel for up to the SecurityTokenLifetime (one hour by default) instead of 30 s. The difference to Part 4 §5.6.2.1 is recorded as an open server finding in plans/ctt-issues.md.

Validated on 2026-09-24 with the reverted code and the new configuration (full run, compared with the run of 2026-09-22 at test-case level):

• Security None 007.js passes and Security Basic256Sha256 005.js has only the C50 CloseSession delay warnings (both failed with 30 s).
• All other parts have the same error signatures as before; the remaining differences are "Response Timestamp shows a delay" warnings from a loaded machine (a back-to-back Session Services run with 30 s and 120 s on an idle machine is identical).
• A & C Refresh2 Err_003.js/Err_004.js and Shelving initialize.js report BadSubscriptionIdInvalid in today's runs with both 30 s and 120 s on the same build, so they are unrelated to the configuration (both passed again in a run on the idle machine with 120 s).

Mantis

32 CTT defects filed on 2026-09-24 (11420–11454, script issues in CTT UA Scripts, native aggregate oracle issues in CTT UA Binary); 12 drafts were already covered by existing reports (including GDS issues 11406–11413 by node-opcua and 11102 for the opc.https/opc.wss endpoint selection); 5 are held back for further investigation. plans/ctt-issues.md links every entry.

CTT documentation (plans/ctt-issues.md, plans/ctt-testing.md)

• ctt-issues.md lists every failing CTT test case with a short abstract and its Mantis issue; the details live in Mantis. It keeps the defects not filed yet, the open questions (U1–U4), the open server findings and the CTT project configuration notes, and no longer lists findings the server has fixed.
• Notable CTT findings of this run: the aggregate oracle lacks the Part 13 Uncertain status and Calculated bit rules that Fix server/core validation, lifecycle and protocol regressions #4477 implements (C48/C49, 24 test cases); the CloseSession "delay in excess of 600ms" warnings are a CTT client artifact (C50: the server answers in 2–5 ms, the CTT stops the Session's SessionThread between stamping and sending); the CTT's FindTokenType rewrites its cached endpoints, so Security User Name Password 2 015.js reports duplicate PolicyIds (C36); A & C Comment passes or skips depending on the date (C39).
• Open server finding: AddNodes after a child rename returns BadNodeIdExists (Fix server/core validation, lifecycle and protocol regressions #4477 × Fix AddNodes scaling and OpenSecureChannel revocation errors found by CTT Monitored Item, Node Management and security runs #4486 interaction, not covered by the CTT).
• ctt-testing.md is a runbook for agents: setup, headless runs, selection generation, reading and comparing results, triage, recipes per conformance group (A & C, Session/Subscription, Monitored Items, security groups with an isolated PKI) and a full partitioned run of every group (about 80 minutes). It points to ctt-issues.md for the failures to expect.

Related Issues

• Follow-up to Fix server/core validation, lifecycle and protocol regressions #4477, Fix sample A&C refresh and alarm timing found by slow CTT Alarms and Conditions runs #4482, Close CTT skips in the reference server sample address space, diagnostics EnabledFlag and project settings #4485, Fix AddNodes scaling and OpenSecureChannel revocation errors found by CTT Monitored Item, Node Management and security runs #4486

Checklist

• I have signed the CLA and read the CONTRIBUTING doc.
• I have added tests that prove my fix is effective or that my feature works and increased code coverage.
• I have added all necessary documentation.
• I have verified that my changes do not introduce (new) build or analyzer warnings.
• I ran all tests locally using the UA.slnx solution against at least .net framework and .net 10, and all passed.
• I fixed all failing and flaky tests in the CI pipelines and all CodeQL warnings.
• I have addressed all PR feedback received.

Validated locally with a full partitioned CTT run of the Release net10.0 reference server (reverted code, ChannelLifetime 120000).

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Cleanup does not account for a still-valid PreviousToken, which can prematurely close reconnecting channels.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Updates TCP inactivity cleanup to retain idle SecureChannels while valid tokens remain, adds regression coverage, and documents full CTT results.

Changes:

• Added token-aware inactivity cleanup.
• Added deterministic regression tests.
• Documented CTT execution results and findings.

File summaries

File	Description
TcpListenerChannel.cs	Determines cleanup eligibility from channel and token state.
TcpTransportListener.cs	Uses the new cleanup eligibility check.
TcpInactivityCleanupRegressionTests.cs	Tests idle, stale, and token-valid channels.
plans/ctt-testing.md	Records full CTT run procedures and results.
plans/ctt-issues.md	Documents CTT findings and resolved server behavior.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Code coverage

✅ Coverage gate passed.

Check	Result	Threshold
✅ Project line rate	87.47% (270642/309394 lines)	>= 70.00%
✅ Project branch rate	77.78%	>= 60.00%
ℹ️ Patch coverage	no changed C# files	-
ℹ️ Baseline delta (advisory)	+13.87 pp	73.60% recorded

Coverage is above the recorded baseline - consider ratcheting coverage-thresholds.json.

_{Thresholds live in coverage-thresholds.json. Whole report before exclusions: line 86.57%, branch 76.93%.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.60%. Comparing base (23be306) to head (7c2ed6a).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4502      +/-   ##
==========================================
- Coverage   81.61%   81.60%   -0.01%     
==========================================
  Files        2069     2069              
  Lines      309394   309394              
  Branches    53699    53699              
==========================================
- Hits       252514   252495      -19     
- Misses      38576    38597      +21     
+ Partials    18304    18302       -2     

Flag	Coverage Δ
actions	81.60% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mrsuciu]

"Behavior change: an idle open channel now stays until its token expires (at most SecurityTokenLifetime, one hour by default) instead of 30 s." This a bit concerning if it could be "exploited" by a rogue client,