Backport additional 4.4.1 servicing fixes - #11292
Amaury Levé (Evangelink) wants to merge 4 commits into
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 0d36ee80-2921-424a-aa64-3dab520a3d6a
Copilot-Session: 0f79d9b9-3240-40e6-bc8e-ed8bfc4cfb2e
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
🧵 Parallel-safety audit — PR #11292Nothing audited here touches process-global state, shared filesystem paths, or
Re-run with
|
🧪 Expert test review — PR #11292This PR's test changes cover two independent efforts: (1) making client "stateful" capability nullable/undeclared across the server-mode protocol, run-settings patching, and MTP client, and (2) hardening the reflection-based MSTest source generator (inheritance/hiding rules,
This advisory comment was generated automatically. Grades are heuristic
|
There was a problem hiding this comment.
Note
🤖 Automated review by GitHub Copilot. Generated by the Expert Code Review workflow. To request a follow-up action, reply by tagging @copilot directly.
| # | Dimension | Verdict |
|---|---|---|
| 17 | Documentation Accuracy | 🟡 1 MODERATE |
✅ 21/22 dimensions clean.
-
GetIsStatefuldoc comment overstates the null-guarantee for third-partyIClientCapabilitiesimplementations (see inline comment)
Summary of what was reviewed:
This PR does three largely independent things:
- Makes
IClientCapabilities.IsStatefulpresence-aware end-to-end (wire format,ClientCapabilitiesrecord,ClientCapabilitiesService, newGetIsStateful()extension,RunSettingsPatcher/MSTestRunSettingsVS-compat fallback) so clients that predate the capability can be distinguished from clients that explicitly declare themselves stateless. This aligns with the newly added.github/copilot-instructions.mdguidance on modeling "unsupported or not declared" separately from an explicit value, and is thoroughly covered by new unit tests across both the STJ and Jsonite deserialization paths (including throwingMessageFormatExceptionfor a non-boolean ornullisStatefulvalue, which is a nice defensive touch for a wire-format field). - Preserves inner-exception messages and stack traces (via a shared
SerializerUtilities.FormatException/ExceptionFlattener) when serializing failed/error/timeout/canceledTestNodeStatePropertyvalues for server mode, instead of only surfacing the outermost exception. Also incidentally cleans up leftover, unresolved git merge-conflict markers (<<<<<<</=======/>>>>>>>) that had been committed intoInternalAPI.Unshipped.txton a prior merge -- good catch, and verified the PR head file is clean of these markers. - Fixes cross-assembly/inheritance correctness bugs in the MSTest source generator's reflection-metadata emission: method resolution at runtime now disambiguates by
DeclaringTypein addition toName/ParameterTypes(fixing overload/hiding ambiguity across a type hierarchy), andTestClassModelBuilder's member-collection walk now correctly implements C#'s member-hiding semantics (a derived member of any kind hides a same-named base method, while overloads on the same type are preserved) instead of a signature-based dictionary key that couldn't distinguish "hidden" from "overloaded." This is exercised by an extensive, well-targeted new test matrix (fields/events/nested types hiding methods,newkeyword shadowing, generic method hiding,dynamicvsobjectequivalence, static/instance hiding, nested closed-generic parameter types). A companion analyzer change relaxes MSTEST0032 (ReviewAlwaysTrueAssertConditionAnalyzer) so it no longer flagsAssert.AreEqual(1, (int)SomeEnum.Value)-style checks that pin an enum's underlying numeric value against a literal -- a legitimate use case previously misclassified as an always-true assertion -- also with thorough positive/negative test coverage across all integral underlying enum types.
All three areas are cross-referenced by corresponding acceptance/unit test updates, and the public/internal API surface changes are correctly declared in PublicAPI.Unshipped.txt / InternalAPI.Unshipped.txt with no init-accessor additions to genuinely new public API (the existing init on ClientCapabilities.IsStateful predates this PR and is grandfathered per repo policy). No threading, resource-disposal, or cross-TFM issues were found in the changed files.
| /// <see langword="true"/> for a stateful client, <see langword="false"/> for a client that explicitly declares | ||
| /// itself stateless, or <see langword="null"/> when the capability was not declared. | ||
| /// </returns> | ||
| public static bool? GetIsStateful(this IClientCapabilities capabilities) |
There was a problem hiding this comment.
[MODERATE] Documentation Accuracy / Public API Design
The XML doc for GetIsStateful states it returns null "when the client did not declare the capability," but that guarantee only holds for the internal ClientCapabilitiesService implementation. Any other IClientCapabilities implementation (including third-party or test-double implementations built against this [Experimental] public interface) falls through to capabilities.IsStateful, which is a non-nullable bool -- so GetIsStateful() can never return null for those implementations, even if the underlying client genuinely never declared the capability. The accompanying unit test (GetIsStateful_ForwardsCustomImplementation) confirms this by construction: a custom IClientCapabilities can only ever yield true/false, never the undeclared state.
Recommendation: Either (a) clarify the XML doc to state explicitly that only the platform's own internal capability implementation can represent the undeclared state, and that custom implementations of IClientCapabilities cannot signal it through this extension, or (b) consider exposing a nullable-aware member directly on the interface (e.g., an optional bool? DeclaredIsStateful alongside the existing non-nullable IsStateful) so the undeclared/false distinction is representable for any implementer, not just the internal record.
There was a problem hiding this comment.
Correction to my previous reply: #11293 was already merged, so it does not contain this documentation clarification. The fix is now in canonical follow-up #11298 targeting main (commit 4965b90) and backport #11299 targeting rel/4.4 (commit b77da21, milestone 80).
Both clarify that only the platform-provided capability service can return null for an undeclared capability; custom implementations return their non-nullable IsStateful value. The accidentally recreated #11293 head branch has been deleted. This supersedes my earlier #11293/b9d5553f0 reference.
Summary
Backports the following merged fixes from
maintorel/4.4in dependency order:The port preserves the existing
rel/4.4servicing changes, including #11258 and the branch-specific source-generation work.Validation
.\build.cmd -pack -bl— passed with 0 warnings and 0 errors.All MSBuild-based validation commands produced binary logs.