5.8 KiB

Raw Blame History

SignalR — TODO

Priority legend

P0 blocker · P1 important · P2 nice-to-have · P3 idea

SIG-T-1: Diagnose first-call null in PostDataAsync

Priority: P2 · Type: Investigation · Related: SIGNALR_ISSUES.md#issue-02

Reproduce the GetProductDtos_80-style first-call null. Add trace logs to PostDataAsync<T> awaiter path and OnReceiveMessage → pending request dictionary lookup. Verify requestId → Task<T> correlation on the very first chunked response of a fresh connection.

SIG-T-2: Document asymmetric send/receive capability

Priority: P1 · Type: Docs

Current behaviour: sender selects BinaryProtocolMode independently; receiver detects the wire format from the first byte (CHUNK_START=200 → chunked path; else non-chunked). This means client and server can run DIFFERENT ProtocolMode settings independently — a core feature amplifying interoperability.

Document in ../SIGNALR_BINARY_PROTOCOL/README.md as a dedicated "Asymmetric send/receive contract" section. Key selling points:

WASM client + AsyncSegment server → works (WASM downgrades send, receives chunked happily)
Third-party client on NuGet can pick any mode → server doesn't care
Gradual mode rollouts possible (no synchronized deploy)

SIG-T-3: Code-level guard for FlushTimeout < ClientTimeoutInterval

Priority: P2 · Type: Feature

AcBinaryHubProtocolOptions.Validate() currently documents (in XML doc) that FlushTimeout should be less than the SignalR HubOptions.ClientTimeoutInterval, but there is no code-level check. Add validation at protocol registration time — if both options are resolvable from the DI scope, verify the constraint and emit a startup warning (or throw, pending decision).

SIG-T-4: `BinaryProtocolMode.Auto` — adaptive send-mode

Priority: P3 · Type: Feature · Related: ../SIGNALR_BINARY_PROTOCOL/SIGNALR_BINARY_PROTOCOL_TODO.md#sbp-t-3

Design: on first received message, inspect first byte to determine peer's send format. On subsequent sends, match it (subject to local-platform constraints, e.g. WASM never actually sends AsyncSegment). Per-HubConnection state. Optional upfront handshake-extension negotiation as an alternative — see wire-level TODO.

SIG-T-5: Server-side NopCommerce plugin — expose `AcBinaryHubProtocolOptions` via appsettings

Priority: P2 · Type: Consumer refactor · Related: SIGNALR_ISSUES.md#sig-i-7, ../../../AyCode.Core/docs/LOGGING/LOGGING_TODO.md#log-t-11

Bind AcBinaryHubProtocolOptions from appsettings.json instead of hardcoding ProtocolMode and constructing a manual Logger instance in PluginNopStartup.cs. This sibling task is paired with LOGGING_TODO.md#log-t-11 (same plugin, logger-setup migration) — best landed in one commit.

Target diff

// In PluginNopStartup.ConfigureServices, BEFORE AddSignalR(...):

// 1. Bind Protocol options from appsettings.json
services.Configure<AcBinaryHubProtocolOptions>(configuration.GetSection("AyCode:SignalR:Protocol"));

// 2. AddSignalR + AddAcBinaryProtocol — drop the inline Action<T> entirely
services.AddSignalR(hubOptions => { /* unchanged */ })
    .AddAcBinaryProtocol();   // ← BuildProtocol auto-resolves IOptions<T> + ILogger<T> from DI

Appsettings.json addition (sibling to `AyCode:Logger`)

{
  "AyCode": {
    "Logger": { "AppType": "Server", "LogLevel": "Debug" },
    "SignalR": {
      "Protocol": {
        "ProtocolMode": "AsyncSegment",
        "BufferSize": 4096,
        "WaitForFlush": true,
        "FlushTimeout": "00:00:10"
      }
    }
  }
}

Consequences / checklist

new Logger(...) line removed from SignalR registration → server-side logger now goes through the DI factory (see LOGGING_TODO.md#log-t-11).
Per-deploy tuning possible without recompile: switching ProtocolMode for diagnostics, extending FlushTimeout for slow links, adjusting BufferSize for different Kestrel slab sizes.
Name stays at "acbinary" default — changing it would break wire-level compat with existing clients.
AcBinaryHubProtocolOptions.Validate() still runs — invalid config (e.g. ProtocolMode=AsyncSegment on a WASM server, which is impossible here but hypothetically) throws at startup.
Plugin doc correction: Nop.Plugin.Misc.AIPlugin/docs/SIGNALR/README.md:22 — the legacy services.AddSingleton<IHubProtocol>(new AcBinaryHubProtocol()) line must be replaced with the real registration. Cross-ref the new AyCode:SignalR:Protocol section here.

Why this belongs in AyCode.Services (framework layer) docs

The gap is consumer-level, but the canonical "server-side registration recipe" is a FRAMEWORK responsibility — LOGGING.md already shows it for the logger side. Adding a matching recipe to ../SIGNALR_BINARY_PROTOCOL/README.md#Registration in Program.cs → Server would prevent the next consumer from making the same mistake. That doc update is part of this TODO's acceptance criteria.

SIG-T-6: Delete legacy `[Obsolete]` JSON-in-Binary wrappers

Priority: P3 · Type: Cleanup · Related: ../../../AyCode.Core/docs/XCUT/XCUT_ISSUES.md#xcut-i-1 (closed canonical), ../../../AyCode.Core/docs/BINARY/BINARY_TODO.md#bin-t-1 (closed)

Now that XCUT-I-1 / BIN-T-1 have landed and the wire format no longer uses JSON-in-Binary, the [Obsolete] wrapper types in IAcSignalRHubClient.cs:60-111 can be deleted:

SignalPostJsonMessage
SignalPostJsonDataMessage<T>
SignalPostMessage<T>
ISignalPostMessage<T>

Gate: verify external consumer projects no longer reference these types — compile-time scan across the workspace + dependent solutions before removal.

Acceptance: all four obsolete types deleted from IAcSignalRHubClient.cs; no CS0618 warnings in any consumer build; remaining doc/glossary mentions either deleted or rewritten as historical references.

5.8 KiB Raw Blame History