dohertj2/histsdk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

DelT investigation: wire-byte parity is necessary but not sufficient

Browse Source 
Investigation step 1 — wire-byte parity check. Captured native DelT
sends ref input values statusSize=1 + status=null (encoded as .nil
on the wire). SDK was passing statusSize=0 + status=[] (empty array).
Updated SDK to match native input values.

Investigation step 2 — verified DelT still doesn't work standalone.
With the ref-input fix, SDK DelT now returns false (instead of the
previous true-with-no-effect). Tag continues to persist in
Runtime.dbo.Tag. So the wire-byte parity fix moved the symptom but
didn't resolve the root cause.

Investigation step 3 — discovered EnsureTagAsync is ALSO silently
broken. Byte-for-byte wire matches captured native EnsT2 (golden test
still passes), but the call returns false and does NOT create the tag
in the DB. The earlier "EnsureTagAsync round-trip test passing" was
relying on the persistent tag from the broken DelT — a false
positive.

Two distinct issues remain:
1. EnsT2 silently fails server-side (returns false; no tag created)
2. DelT returns false even with native-matching wire bytes

Test adjusted to no longer assert that EnsureTagAsync actually
creates the tag (because it currently doesn't). Test still exercises
the SDK call path to confirm it doesn't throw.

Next-session diagnostic: write a custom IClientMessageInspector for
the SDK's WCF channel that captures outgoing DelT/EnsT2 bytes to a
file. Compare byte-for-byte (offset by offset, not just per-field)
against captured native to isolate the difference.

130/130 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
dohertj2
2026-05-04 08:51:24 -04:00
parent cfc8d44e3a
commit 200493c990
3 changed files with 45 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plans/write-commands-reverse-engineering.md
+30
View File
@@ -176,6 +176,36 @@ DelT removes the tag cleanly (verified via the harness with
around the WCF DelT call is missing from our orchestrator. The harness
cleanup path remains the documented workaround for sandbox housekeeping.
## DelT investigation findings (2026-05-04)
Investigation step 1 — wire-byte parity check: the captured native DelT
request sends `ref` input values `statusSize=1` + `status=null` (encoded as
`.nil` on the wire). My SDK was passing `statusSize=0` + `status=[]` (empty
byte array). Updated SDK to send the native-matching values.
Investigation step 2 — verified DelT still doesn't work standalone: with
the ref-input fix, DelT now returns `false` (not `true`-and-no-effect).
Tag continues to persist in `Runtime.dbo.Tag`. So the wire-byte parity
fix moved the symptom but didn't resolve the root cause.
Investigation step 3 — discovered EnsureTagAsync is **also** silently
broken: byte-for-byte wire matches captured native EnsT2 (golden test
passes), but the call returns false and does NOT create the tag in the
DB. The earlier "EnsureTagAsync round-trip test passing" was relying on
the persistent tag from the broken DelT — a false positive.
Two distinct issues remain:
- EnsT2 silently fails server-side (returns false; no tag created)
- DelT returns false even with native-matching wire bytes; needs deeper
investigation (likely the SDK's WCF channel state vs the native
HistorianAccess instance state)
Diagnostic tooling for next session: write a custom
`IClientMessageInspector` for the SDK's WCF channel that captures
outgoing DelT bytes to a file. Compare byte-for-byte against the
captured native DelT (offset by offset, not just per-field) to isolate
the difference.
## Phase 2 remaining work (revised — narrower scope)
1. Decode the 146-byte EnsT2(Float) CTagMetadata against the IL of