6.0 KiB

Raw Blame History

SignalR — TODO

Priority legend

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

ACCORE-SIG-T-J2P5: Diagnose first-call null in PostDataAsync

Priority: P2 · Type: Investigation · Related: SIGNALR_ISSUES.md#accore-sig-i-l5k3

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.

ACCORE-SIG-T-W8R3: 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)

ACCORE-SIG-T-D7Q4: 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).

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

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

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.

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

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

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#accore-log-t-w4h9 (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,
        "FlushPolicy": "PerChunk",
        "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#accore-log-t-w4h9).
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.

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

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

Now that ACCORE-XCUT-I-X8Q1 / ACCORE-BIN-T-S8P4 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.

6.0 KiB Raw Blame History