Closed the blind spot the zero-rows conclusion had leaned on: prior cycles used wire
capture (instrument-grpc-nonstream hooks only byte[] params), blind to gRPC metadata,
interceptors, channel options. Read the stock managed source directly
(histsdk-2023r2-analysis/decompiled/Archestra.Historian.GrpcClient + HistorianAccess;
the pure-managed assemblies decompile cleanly though mixed-mode aahClientManaged crashes
ILSpy).
Findings:
- GrpcClientBase.InitializeBase uses GrpcWebHandler (GrpcWebMode, HttpVersion 1.1) — the
stock client speaks gRPC-Web over HTTP/1.1, the SAME transport as our SDK. This corrects
the premise of hypothesis #1: there was never a native Grpc.Core HTTP/2 path to differ
from; the stock client returning 50 rows is itself gRPC-Web. The HTTP/2 disproof's
conclusion stands and is reinforced (identical transport on both sides).
- m_metadata on every RPC (incl. StartEventQuery/GetNextEventQueryResultBuffer) is only
grpc-internal-encoding-request: gzip — exactly our header set. The ClientInterceptor is
a no-op (empty LogCall). So the "invisible per-connection metadata/header" blind spot is
confirmed empty — no hidden client-side identity the byte[] capture missed.
- CreateEventQuery/StartQuery/MoveNext are not in managed code; the managed
GrpcRetrievalClient.StartEventQuery is a thin one-RPC stub. The query logic lives in the
native C++/CLI HistorianClient core — consistent with the working-set being native/server-side.
Every client-controllable layer is now confirmed identical by reading the stock source,
not just by wire match: request bytes, transport, channel options, gRPC metadata,
interceptor. The remaining difference is below the managed surface / server-side.
Conclusion unchanged: gRPC event-row retrieval is auth-solved / retrieval-server-gated.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B6mcaT2PjRFKcogzp9UkfC
Joseph Doherty
6cf4dd13fe