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.
This commit is contained in:
@@ -14,6 +14,7 @@ use tokio::sync::{mpsc, Mutex};
|
||||
use tokio_stream::wrappers::{ReceiverStream, TcpListenerStream};
|
||||
use tonic::transport::Server;
|
||||
use tonic::{Request, Response, Status};
|
||||
use zb_mom_ww_mxgateway_client::error::ensure_mxaccess_success;
|
||||
use zb_mom_ww_mxgateway_client::generated::mxaccess_gateway::v1::mx_access_gateway_server::{
|
||||
MxAccessGateway, MxAccessGatewayServer,
|
||||
};
|
||||
@@ -337,6 +338,57 @@ fn authentication_and_authorization_statuses_are_distinct_and_redacted() {
|
||||
assert!(!auth.to_string().contains("visible_secret"));
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn command_reply_validation_fixtures_branch_on_category_and_negative_hresult() {
|
||||
// The shared behavior fixtures pin both reply-validation rules: a status
|
||||
// entry fails iff its category is not OK (the raw `success` member is
|
||||
// diagnostics only) and an HRESULT fails iff it is present and negative.
|
||||
for (fixture, expect_failure) in [
|
||||
("register.ok.reply.json", false),
|
||||
("write.status-category-error-success-set.reply.json", true),
|
||||
("write.status-category-ok-success-zero.reply.json", false),
|
||||
("write.hresult-s-false.reply.json", false),
|
||||
("write.hresult-e-fail.reply.json", true),
|
||||
] {
|
||||
let reply = command_reply_fixture(fixture);
|
||||
let result = ensure_mxaccess_success(reply);
|
||||
|
||||
assert_eq!(
|
||||
result.is_err(),
|
||||
expect_failure,
|
||||
"fixture {fixture} expected failure = {expect_failure}, got {result:?}"
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn status_entry_verdict_ignores_the_raw_success_member() {
|
||||
// Edges the fixtures cannot express: an OK category always passes and an
|
||||
// unspecified category always fails, whatever `success` carries.
|
||||
for (category, success, expect_failure) in [
|
||||
(MxStatusCategory::Ok, 0, false),
|
||||
(MxStatusCategory::Ok, 1, false),
|
||||
(MxStatusCategory::CommunicationError, 1, true),
|
||||
(MxStatusCategory::Unspecified, 1, true),
|
||||
] {
|
||||
let reply = MxCommandReply {
|
||||
protocol_status: Some(ok_status("command ok")),
|
||||
statuses: vec![MxStatusProxy {
|
||||
success,
|
||||
category: category as i32,
|
||||
..MxStatusProxy::default()
|
||||
}],
|
||||
..MxCommandReply::default()
|
||||
};
|
||||
|
||||
assert_eq!(
|
||||
ensure_mxaccess_success(reply).is_err(),
|
||||
expect_failure,
|
||||
"category {category:?} with success {success} expected failure = {expect_failure}"
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn command_error_display_keeps_raw_reply_accessible() {
|
||||
let reply = mxaccess_failure_reply();
|
||||
@@ -1358,6 +1410,52 @@ fn event(sequence: u64) -> MxEvent {
|
||||
}
|
||||
}
|
||||
|
||||
/// Load a shared command-reply fixture into an [`MxCommandReply`].
|
||||
///
|
||||
/// The fixtures are protobuf JSON, which prost cannot parse directly, so this
|
||||
/// reads the fields the reply-validation rules actually consume (`hresult` and
|
||||
/// the status `success`/`category` pair) and rebuilds the message. Enum names
|
||||
/// resolve through the generated `from_str_name`, so a fixture naming a
|
||||
/// category the contract does not define fails the test rather than silently
|
||||
/// degrading to `Unspecified`.
|
||||
fn command_reply_fixture(file_name: &str) -> MxCommandReply {
|
||||
let fixture = behavior_fixture(&format!("command-replies/{file_name}"));
|
||||
|
||||
let statuses = fixture["statuses"]
|
||||
.as_array()
|
||||
.map(Vec::as_slice)
|
||||
.unwrap_or_default()
|
||||
.iter()
|
||||
.map(|status| {
|
||||
let category_name = status["category"].as_str().unwrap();
|
||||
MxStatusProxy {
|
||||
success: status["success"].as_i64().unwrap() as i32,
|
||||
category: MxStatusCategory::from_str_name(category_name)
|
||||
.unwrap_or_else(|| panic!("unknown status category {category_name}"))
|
||||
as i32,
|
||||
detail: status["detail"].as_i64().unwrap_or_default() as i32,
|
||||
diagnostic_text: status["diagnosticText"]
|
||||
.as_str()
|
||||
.unwrap_or_default()
|
||||
.to_owned(),
|
||||
..MxStatusProxy::default()
|
||||
}
|
||||
})
|
||||
.collect();
|
||||
|
||||
MxCommandReply {
|
||||
session_id: fixture["sessionId"].as_str().unwrap_or_default().to_owned(),
|
||||
correlation_id: fixture["correlationId"]
|
||||
.as_str()
|
||||
.unwrap_or_default()
|
||||
.to_owned(),
|
||||
protocol_status: Some(ok_status("command ok")),
|
||||
hresult: fixture["hresult"].as_i64().map(|hresult| hresult as i32),
|
||||
statuses,
|
||||
..MxCommandReply::default()
|
||||
}
|
||||
}
|
||||
|
||||
fn behavior_fixture(path: &str) -> Value {
|
||||
let path = std::path::Path::new(env!("CARGO_MANIFEST_DIR"))
|
||||
.join("../proto/fixtures/behavior")
|
||||
|
||||
Reference in New Issue
Block a user