diff --git a/design/followups.md b/design/followups.md index 713f590..0f8ddb5 100644 --- a/design/followups.md +++ b/design/followups.md @@ -74,6 +74,43 @@ move to `## Resolved` with a date + commit hash. For the per-step body of every line listed in the cumulative execution log, see the matching commit message — each commit is a single F-number step with its own scope, fixtures, test count delta, and follow-up notes. The detailed per-step write-ups previously inlined here added little beyond what `git show ` provides. +### F34 — Publish response: decoder reads 0 values where .NET sees real values +**Severity:** P2 — only affects the F26 stream's data flow against MxDataProvider; the canonical-XML signing for Publish itself is verified working (server accepts the request, returns a non-fault response). +**Source:** Live `cargo run -p mxaccess --example asb-subscribe` against the local AVEVA install, 2026-05-06. + +**Evidence.** Side-by-side comparison after the .NET probe and Rust client both ran `--subscribe` against the same `TestChildObject.TestInt` tag: + +``` +.NET probe (working): + publish[0]_error=0x00000020 status=0x00000000 specific=0x00000000 + published_event[0]=item:TestChildObject.TestInt id:18446462598732840962 + type:4 quality:0x00C0 timestamp:... preview:99 + publish[0]_value[0]=item: id:... id_specified:True type:4 length:4 + payload_len:4 preview:99 + +Rust client (this followup): + poll 0: 0 value(s); result_code=Some(32) success=Some(false) + poll 1: 0 value(s); result_code=Some(32) success=Some(false) + ... (8 polls total, 0 values each) +``` + +Both sides see the same `result_code=32` (= `AsbErrorCode.PublishComplete`, informational per `AsbResultMapping.cs:37` + `ToResult:122-129` which treats it like `Success`). Both sides see `successField=false`. **But .NET extracts a value while we extract zero.** + +**Confirmed not the cause:** +- ✅ `SampleInterval` unit (was 10_000_000 in example, fixed to `1000` ms — matches `MxAsbDataClient.cs:441`'s `ulong sampleInterval = 1000` default). +- ✅ Treating `result_code=32` as informational (the F26 narrower-bail fix matches the .NET logic exactly). +- ✅ Canonical-XML signing of the `PublishRequest` (the server returns a typed response, not a SOAP fault). +- ✅ `MonitoredItemValue` IS `IAsbCustomSerializableType` (`AsbContracts.cs:1035`), so it travels via the `{bytes}` binary fast-path same as `Read`'s Values path which works. + +**Open hypotheses (each needs wire-capture verification via `examples/asb-relay.rs` middleman with the .NET probe):** +1. Wire shape mismatch: server may emit Values via a different element/namespace than `` in this case (some kind of dynamic dict id we don't resolve), so our `collect_asbidata_payloads` walking by name misses it. +2. Status array shape: a 0-length Status (empty array, 4-byte `count=0`) may render as a populated `` containing just `[0,0,0,0]`; our decoder reads `payloads[0]` as Status (correctly empty) and `payloads[1]` as Values — but if the server's wire only has 1 ASBIData (Status was omitted entirely, not empty-but-present), `payloads[1]` would BE the Values payload getting mis-read as Status. +3. `decode_monitored_item_value_array` (which builds on `MonitoredItemValue::decode` at `contracts.rs:277`) may have a subtle bug — `MonitoredItemValue` carries `ItemIdentity + RuntimeValue + AsbVariant userdata` per `cs:1064-1068`; if the wire bytes don't match that order or include extra fields, the count read at offset 0 would be wrong. + +**Resolves when:** A middleman trace via `examples/asb-relay.rs` between the .NET probe and MxDataProvider for a working subscribe-flow exposes the actual wire bytes of a `PublishResponse` carrying values. Compare against `decode_publish_response`'s expectations and reconcile (likely a `MonitoredItemValue` byte-layout fix or a Values-payload-locator fix). + +**Adjacent observation worth noting:** `AddMonitoredItemsResponse` shows the same symptom shape — our trace reports `add status: 0 item(s); result_code=Some(0) success=Some(true)` while the .NET probe reports `add_monitored_status[0]=item:TestChildObject.TestInt id:18446462598732840962 ...`. Same `IAsbCustomSerializableType`-wrapped Status array; same "0 items where .NET sees 1". These two decoders likely fail for the same root reason and a single fix should close both. + ### F27 — Constant-time DH `mod_exp` (swap `num-bigint` → `crypto-bigint::BoxedUint`) **Severity:** P2 (security regression vs the long-term Rust target — but at parity with the .NET reference today, so not a release-blocker) **Source:** F23 (`crates/mxaccess-asb-nettcp/src/auth.rs:179,303`); originally flagged in `design/30-crate-topology.md:269-274` and the project's `review.md` MAJOR finding. diff --git a/rust/crates/mxaccess-asb/src/operations.rs b/rust/crates/mxaccess-asb/src/operations.rs index eb69fad..a0910ae 100644 --- a/rust/crates/mxaccess-asb/src/operations.rs +++ b/rust/crates/mxaccess-asb/src/operations.rs @@ -855,9 +855,19 @@ pub fn build_add_monitored_items_request_body( /// also has optional Active, TimeDeadband, ValueDeadband, and UserData /// fields. Those are deferred to a later F25 iteration once a live /// capture confirms the wire-byte form. +/// +/// **`sample_interval` unit is milliseconds**, NOT 100-ns ticks. The +/// .NET reference's `MxAsbDataClient.AddMonitoredItems` defaults to +/// `ulong sampleInterval = 1000` (= 1 second), passed straight to the +/// wire (`MxAsbDataClient.cs:441`). Sending tick-units (e.g. +/// `10_000_000` for "1 second in 100-ns ticks") makes MxDataProvider +/// schedule the next sample ~2.8 hours out — `Publish` polls then +/// always come back empty until the misinterpreted timer expires. +/// Verified live 2026-05-06. #[derive(Debug, Clone, PartialEq)] pub struct MinimalMonitoredItem { pub item: ItemIdentity, + /// Sample interval in **milliseconds** (matches the .NET wire form). pub sample_interval: u64, pub buffered: bool, } diff --git a/rust/crates/mxaccess/examples/asb-subscribe.rs b/rust/crates/mxaccess/examples/asb-subscribe.rs index 9703fa4..afd3b98 100644 --- a/rust/crates/mxaccess/examples/asb-subscribe.rs +++ b/rust/crates/mxaccess/examples/asb-subscribe.rs @@ -132,9 +132,15 @@ async fn main() -> Result<(), Box> { // -- Subscribe-flow ---------------------------------------------------- if env.run_subscribe { eprintln!("creating subscription [canonical XML CreateSubscription] (max_queue=100, sample=1s)"); - let sample_interval_ticks: u64 = 10_000_000; // 1 second + // SampleInterval is in **milliseconds** on the wire — the .NET + // reference's `MxAsbDataClient.CreateSubscription` / + // `AddMonitoredItems` default is `ulong sampleInterval = 1000` + // (`MxAsbDataClient.cs:396,441`). Sending 10_000_000 here would + // be interpreted as ~2.8 hours between samples and the publish + // poll would always come back empty. + let sample_interval_ms: u64 = 1000; let max_queue_size: i64 = 100; - let sub_response = match client.create_subscription(max_queue_size, sample_interval_ticks).await { + let sub_response = match client.create_subscription(max_queue_size, sample_interval_ms).await { Ok(r) => r, Err(e) => { eprintln!(" create_subscription failed: {e}"); @@ -151,7 +157,7 @@ async fn main() -> Result<(), Box> { let monitored = vec![MinimalMonitoredItem::new( ItemIdentity::absolute_by_name(&env.tag), - sample_interval_ticks, + sample_interval_ms, )]; eprintln!("adding monitored items [canonical XML AddMonitoredItems]");