fix(CLI-37,CLI-38): make status/HRESULT reply validation conformant across all five clients

One cross-client conformance pass; also closes first-cycle CLI-08. CLI-37: an MxStatusProxy entry is a failure iff `category != MX_STATUS_CATEGORY_OK`. The proto contract has always said so — `success` is the raw 16-bit COM member carried verbatim for diagnostics, not a boolean — but four clients branched on `success` alone and .NET required both, so the same gateway reply produced opposite verdicts per language. An absent entry stays success; a present entry with an UNSPECIFIED category is a failure, because the worker always maps a category and an unmapped one is not proven OK. CLI-38: a reply fails on HRESULT iff `hresult` is present and negative, so positive COM success codes such as S_FALSE (1) pass. .NET/Go/Java used `!= 0`, which errored on a parity-preserving S_FALSE that Python and Rust accepted. This makes the existing ClientLibrariesDesign.md claim true rather than rewriting the doc to describe the divergence. Four shared fixtures pin both rules cross-client, and each language suite also carries a table test for the two edges a fixture cannot express (absent entry, UNSPECIFIED category). A Java test fake that built a status with a bare `setSuccess(1)` and no category is fixed — under the category rule that reply was never a success.
2026-08-07 06:00:58 -04:00
parent cf66ebbcfb
commit d6b2f24c3f
30 changed files with 631 additions and 40 deletions
@@ -32,6 +32,57 @@ public sealed class MxCommandReplyExtensionsTests
        Assert.Contains("0x80040200", exception.Message);
    }

+    /// <summary>Verifies that a non-OK status category fails even when the raw success member is set.</summary>
+    [Fact]
+    public void EnsureMxAccessSuccess_WithNonOkCategoryAndSuccessSet_Throws()
+    {
+        MxCommandReply reply = ReadReplyFixture(
+            "write.status-category-error-success-set.reply.json");
+
+        reply.EnsureProtocolSuccess();
+        MxAccessException exception = Assert.Throws<MxAccessException>(
+            reply.EnsureMxAccessSuccess);
+
+        Assert.Equal(1, Assert.Single(exception.Statuses).Success);
+        Assert.Contains("CommunicationError", exception.Message, StringComparison.Ordinal);
+    }
+
+    /// <summary>Verifies that an Ok status category succeeds even when the raw success member is zero.</summary>
+    [Fact]
+    public void EnsureMxAccessSuccess_WithOkCategoryAndZeroSuccess_ReturnsReply()
+    {
+        MxCommandReply reply = ReadReplyFixture(
+            "write.status-category-ok-success-zero.reply.json");
+
+        Assert.Equal(0, Assert.Single(reply.Statuses).Success);
+        Assert.Same(reply, reply.EnsureProtocolSuccess());
+        Assert.Same(reply, reply.EnsureMxAccessSuccess());
+    }
+
+    /// <summary>Verifies that a positive HResult (S_FALSE) is a COM success code, not a failure.</summary>
+    [Fact]
+    public void EnsureMxAccessSuccess_WithPositiveHResult_ReturnsReply()
+    {
+        MxCommandReply reply = ReadReplyFixture("write.hresult-s-false.reply.json");
+
+        Assert.Equal(1, reply.Hresult);
+        Assert.Same(reply, reply.EnsureProtocolSuccess());
+        Assert.Same(reply, reply.EnsureMxAccessSuccess());
+    }
+
+    /// <summary>Verifies that a negative HResult fails even when every status entry is Ok.</summary>
+    [Fact]
+    public void EnsureMxAccessSuccess_WithNegativeHResult_Throws()
+    {
+        MxCommandReply reply = ReadReplyFixture("write.hresult-e-fail.reply.json");
+
+        reply.EnsureProtocolSuccess();
+        MxAccessException exception = Assert.Throws<MxAccessException>(
+            reply.EnsureMxAccessSuccess);
+
+        Assert.Equal(-2147467259, exception.HResultCode);
+    }
+
    /// <summary>Verifies that session-not-found protocol failures throw the correct gateway exception.</summary>
    [Fact]
    public void EnsureProtocolSuccess_WithSessionFailure_ThrowsSessionException()