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

docs(grpc): record DelTep multiplexed-channel probe as disproven

Browse Source 
README transport matrix + grpc-tooling-completion.md §Out-of-scope: the gRPC
multiplexed-channel hypothesis for DeleteTagExtendedProperties was probed live
2026-06-22 and disproven — primes succeed on the shared channel but DelTep is
still rejected (native code=1), property survives. Stays server-blocked on both
transports, not shipped.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B6mcaT2PjRFKcogzp9UkfC
This commit is contained in:
Joseph Doherty
2026-06-22 06:55:05 -04:00
parent 2bd86e4e83
commit b3417c2f6a
2 changed files with 14 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plans/grpc-tooling-completion.md
+13 -2
View File
@@ -140,8 +140,19 @@ _Original notes (still the reference for the registration replay):_
### Out of scope
- `ReadBlocks` (`StartBlockRetrievalQuery`) — never captured on either transport; leave
throwing `ProtocolEvidenceMissingException`.
- `DeleteTagExtendedProperties` — server-blocked on WCF (per-connection working set);
gRPC's single multiplexed channel *might* fix it — opportunistic probe only.
- `DeleteTagExtendedProperties` — ❌ **PROBED 2026-06-22, multiplexed-channel hypothesis DISPROVEN.**
The WCF block (server resolves the property from a per-connection working set the SDK's separate
per-service channels can't populate) is NOT lifted by gRPC. The probe
(`HistorianGrpcTagWriteOrchestrator.ProbeDeleteTagExtendedPropertiesAsync`) runs the native
`GetTgByNm` → `GetTepByNm` → `DelTep` sequence over ONE write-enabled (0x401) session on gRPC's
single shared channel. Live against the 2023 R2 server (History iface 12): both primes succeed on the
shared channel (`TgPrimeBytes=98`, `TepPrimePages=1`) yet `DelTep` is still rejected with native
**code=1** (the 5-byte error buffer's byte0=132 is the universal `0x84` marker, not a code) and the
property survives. Conclusion: the working set the server consults is populated by something the SDK
can't reproduce even over one connection — most likely the native client's in-process registration
object, not the wire session. Stays server-blocked on BOTH transports; not shipped publicly. Pinned
by the gated negative test `DeleteTagExtendedProperties_OverGrpc_ProbeMultiplexedChannel` (flips if a
future server/registration lifts the wall).
## Live verification setup (every live run)