Joseph Doherty
5845b5eb12
rust / build / test / clippy / fmt (push) Has been cancelled
Three of seven proven types now round-trip end-to-end against the live MxDataProvider: ✅ Int32 (type_id 4) — TestChildObject.TestInt = 99 ✅ String (type_id 10) — TestChildObject.TestString = "mxaccesscli verified 17778523775" (UTF-16LE on wire) ✅ Bool (type_id 17) — DelmiaReceiver_001.TestAttribute = 0 A SQL probe of the live Galaxy (`gobject ⨝ package ⨝ dynamic_attribute` grouped by `mx_data_type`) shows only types {1=Bool, 2=Int32, 5=String} have deployed instances. Float/Double/DateTime/ Duration/array shapes are not in this Galaxy, so the remaining four type-matrix bullets in F32 are gated on Galaxy-side provisioning that's outside the Rust port's scope. The M5 DoD #3 was always going to bottom out at "what types are deployed in the test environment." Code changes: - `register_items` retry budget bumped: 10 attempts (was 5) with `200 * attempt` ms backoff (was 100 * attempt). Worst-case wait ~11 s, well within user-perceived latency on a one-shot RPC. The .NET reference's 5×100 ms didn't always cover the live AVEVA install's auth-state-commit latency on this hardware. - `AsbClient::connect` adds a 250 ms `tokio::time::sleep` immediately after the one-way `AuthenticateMe` send. The server processes the request asynchronously; without an initial settle, the per-op retry loop frequently exhausts its budget on the InvalidConnectionId race even on the FIRST register attempt. 250 ms is short enough to be invisible and long enough to absorb the typical commit delay. - `examples/asb-subscribe.rs` now prints `result_code` and `success` alongside the status count so the user can see when register is hitting the retry-exhausted state. Live flakiness note: the AuthenticateMe race is not fully deterministic — after many back-to-back test runs the live server appears to degrade (presumably pending-connection table fills) and the retry budget exhausts on EVERY tag, not just one. A 30-second cool-down restores reliability. Production deployments with a single long-lived session are unlikely to hit this. F32 status doc captures the observation. Workspace: 711 unit tests pass. Clippy clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
design/ — Rust port architectural plan
This folder is the design contract for the Rust replacement of AVEVA/Wonderware MXAccess. It is the gap between the .NET reference in src/ and the Rust crates that will be written under a sibling rust/ workspace (per CLAUDE.md).
The folder is structured as a small set of focused documents. Read in order; each builds on the previous.
| File | Purpose |
|---|---|
00-overview.md |
Mission, two-layer goal, architectural principles, non-goals |
10-raw-layer.md |
Byte-accurate raw MXAccess layer (codec + transport + session) |
20-async-layer.md |
Idiomatic Tokio async layer on top of the raw layer |
30-crate-topology.md |
Cargo workspace, crates, dependencies, build/test commands |
40-protocol-invariants.md |
Bill of materials: IIDs, opnums, envelope/handle bytes |
50-error-model.md |
MxStatus, error types, panic/cancellation policy |
60-roadmap.md |
Milestones M0..M6, validation strategy |
70-risks-and-open-questions.md |
Parity gaps, unproven flows, cross-platform constraints |
dependencies.md |
Cross- and within-milestone parallelism map; agent budget per phase |
review.md |
Adversarial review log (BLOCKER/MAJOR/MINOR/NIT findings, all resolved) |
prompt.md |
/loop driver prompt for autonomous M2–M6 execution |
followups.md |
Open / resolved deferred work items; auto-triaged by prompt.md Step 0 (created on first /loop run if missing) |
The design is grounded in the .NET reference at src/ and the protocol artifacts in docs/, analysis/, and captures/. Do not introduce protocol behavior in these documents that is not already proven in the reference. When adding a new claim about wire format, cite either:
- a
.csfile path insrc/MxNativeCodec/,src/MxNativeClient/, orsrc/MxAsbClient/, or - a
docs/*.mdspec file, or - a
captures/0NN-frida-*directory oranalysis/frida/*.tsvrow.
This folder is documentation, not code. When the Rust workspace is created, the design here is the contract it must satisfy. When evidence in captures/ invalidates a design decision here, update the design first, then the code.
Reading order
- New contributor: 00 → 30 → 10 → 40 → 20 → 50 → 60 → 70.
- Protocol question: 40 first, then the relevant section of 10.
- API question: 20 first, then 50.
- Planning a milestone: 60 first, cross-reference 70 for blockers.
- Scheduling concurrent work:
dependencies.mdfor the per-phase parallelism map. - Driving M2–M6 autonomously via
/loop:prompt.md(and thefollowups.mdtriage log it maintains).