e5b31fadb1
Live attempt against AVEVA on this dev host produced two artefacts:
**`crates/mxaccess-compat/tests/lmx_write_complete_live.rs`** — the
F54 OnWriteComplete round-trip test. Compiles + runs against the
live AVEVA install via either path:
- `--features live-windows-com` (preferred): uses
`Session::connect_nmx_auto` so the COM activation reference is
held in-process for the duration of the test.
- Default features (fallback): shells out to
`MxNativeClient.Probe --probe-resolve-oxid-managed-ntlm-integrity`
+ `--probe-remqi-managed` to learn the per-session NMX endpoint +
INmxService2 IPID, then uses `Session::connect_nmx`.
Both code paths are wired and the test runs through endpoint
resolution + IPID extraction successfully. The connect step itself
fails with `Status { detail: 1722 }` (RPC_S_SERVER_UNAVAILABLE).
**`crates/mxaccess-rpc/examples/com-marshal-probe.rs`** — minimal
one-shot binary that calls
`marshal_activated_iunknown_objref("NmxSvc.NmxService",
DifferentMachine)` in isolation. Confirms the COM activation +
CoMarshalInterface chain works fine standalone (returns a 338-byte
OBJREF with valid OXID/IPID structure). The 1722 in the live test
is therefore downstream of the activation — likely a COM-apartment
threading interaction with the tokio multi-thread runtime.
This is an F12-related issue (auto-resolve hardening), not an F54
issue. F54's correctness is covered by the existing unit-level
integration tests:
- `mxaccess::session::tests::router_populates_operation_status_context_from_pending_ops_fifo`
- `mxaccess::session::tests::write_handle_correlates_with_router_emitted_status`
- `mxaccess_compat::tests::drain_routes_write_status_to_on_write_complete`
- `mxaccess_compat::tests::drain_routes_non_write_status_to_on_operation_complete`
`design/followups.md` F49 entry updated to reflect:
- F54 added as a fifth row in the live-verification scope.
- "Live attempt 2026-05-06" sub-section documents the 1722 issue +
what was verified (.NET probe end-to-end works against same
install; Rust COM activation works in isolation; the failure is
Rust-port-specific to `connect_nmx_auto` under tokio).
- F49 now Blocked-by F12 hardening (the 1722 path).
New `live-windows-com` feature on `mxaccess-compat` propagates to
`mxaccess/windows-com` for the test binary.
Workspace 824 → 824 tests; clippy + rustdoc clean across both
feature configurations.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
43 lines
1.4 KiB
Rust
43 lines
1.4 KiB
Rust
//! One-shot probe: run `marshal_activated_iunknown_objref` standalone
|
|
//! to isolate which step in the NMX activation pipeline is failing
|
|
//! with RPC_S_SERVER_UNAVAILABLE (1722) when called from cargo test.
|
|
//!
|
|
//! Run with:
|
|
//! ```text
|
|
//! cargo run -p mxaccess-rpc --example com-marshal-probe --features windows-com
|
|
//! ```
|
|
|
|
#[cfg(all(windows, feature = "windows-com"))]
|
|
fn main() {
|
|
use mxaccess_rpc::com_objref_provider::{
|
|
marshal_activated_iunknown_objref, MarshalContext,
|
|
};
|
|
|
|
eprintln!("step 1: marshal_activated_iunknown_objref(NmxSvc.NmxService, DifferentMachine)");
|
|
match marshal_activated_iunknown_objref("NmxSvc.NmxService", MarshalContext::DifferentMachine) {
|
|
Ok(blob) => {
|
|
eprintln!("OK: {} bytes", blob.len());
|
|
eprintln!("first 64 bytes (hex):");
|
|
for chunk in blob.iter().take(64).enumerate() {
|
|
if chunk.0 % 16 == 0 {
|
|
eprint!("\n ");
|
|
}
|
|
eprint!("{:02x} ", chunk.1);
|
|
}
|
|
eprintln!();
|
|
}
|
|
Err(e) => {
|
|
eprintln!("FAIL: {e}");
|
|
std::process::exit(1);
|
|
}
|
|
}
|
|
}
|
|
|
|
#[cfg(not(all(windows, feature = "windows-com")))]
|
|
fn main() {
|
|
eprintln!(
|
|
"com-marshal-probe requires Windows + the windows-com feature: \
|
|
cargo run -p mxaccess-rpc --example com-marshal-probe --features windows-com"
|
|
);
|
|
}
|