2.0 KiB
2.0 KiB
XCUT — Cross-cutting Known Issues
Canonical entries for known issues that span two or more topics. See README.md in this folder for the cross-cutting convention.
For planned cross-cutting work, see XCUT_TODO.md.
XCUT-I-1: JSON-in-Binary request parameters
Status: Open Affects: BINARY serializer (wire format) ↔ SIGNALR transport (envelope) ↔ all consuming projects (caller code)
Description
Client→server request parameters currently travel as JSON inside a Binary envelope:
SignalPostJsonDataMessage<T>is the current envelope- Response path already uses pure Binary (no JSON)
- Asymmetry: request is JSON-in-Binary, response is Binary
Why it spans multiple topics
- BINARY side: the serializer has to special-case JSON payloads inside a Binary stream; ideal Binary-only flow is broken on the request side.
- SIGNALR side: the transport carries the JSON-wrapped Binary payload;
SignalPostJsonDataMessage<T>is a SignalR-level concept. - Consumer side: every caller sends requests via this asymmetric path; changing the wire format requires coordinated client + server + all-consuming-project updates.
Planned migration (tracked in TODO)
BINARY_TODO.md#bin-t-1— "Replace JSON-in-Binary request parameters"- Acceptance:
SignalPostJsonDataMessage<T>replaced bySignalPostBinaryDataMessage<T>(or equivalent); no JSON round-trip on the wire for request params; benchmarks confirm no regression.
Do NOT attempt as a side-effect
Any client or server change in isolation will break the other side. Requires:
- Binary envelope for both request and response defined
- Client code updated to serialize via Binary
- Server code updated to deserialize via Binary
- All consuming projects rebuilt against new API
- Version bump coordinated
Cross-references
- BINARY_ISSUES.md (
../BINARY/BINARY_ISSUES.md#xcut-i-1): cross-ref pointing here - SIGNALR_ISSUES.md (
../../../AyCode.Services/docs/SIGNALR/SIGNALR_ISSUES.md#xcut-i-1): cross-ref pointing here - BINARY_TODO.md#bin-t-1: migration plan