Recent "expose WebSocket configuration for Polymarket and Kalshi" commit configures the wrong layer — core's PolymarketWebSocketConfig/KalshiWebSocketConfig remain unreachable, #1052/#1053 not actually fixed #1759

Gap

Commit 6d46824 ("feat(sdk): expose WebSocket configuration for Polymarket and Kalshi") adds a websocket constructor option to both SDKs' Polymarket/Kalshi classes. This looks like it closes open issues #1052 (PolymarketExchangeOptions.websocket not passable through either SDK) and #1053 (KalshiExchangeOptions.websocket not passable through either SDK) — but it does not. The new option is a same-named, unrelated config object (WsClientConfig) that tunes the local SDK↔sidecar transport socket (sdks/typescript/pmxt/ws-client.ts), not the venue's actual WebSocket feed that core defines as PolymarketWebSocketConfig/KalshiWebSocketConfig. The field names don't even overlap between the two. #1052/#1053 should remain open — the commit doesn't address them, and its use of the identical option name (websocket) risks the false impression that they're resolved.

Core

The real per-venue configs the original issues are about, still completely unreachable via the sidecar path:

• core/src/exchanges/polymarket/websocket.ts:53-68 — PolymarketWebSocketConfig { reconnectIntervalMs, flushIntervalMs, watcherConfig, watchTimeoutMs, userChannelCreds, connectionTimeoutMs, snapshotFallbackMs }, exposed as PolymarketExchangeOptions.websocket at core/src/exchanges/polymarket/index.ts:56.
• core/src/exchanges/kalshi/websocket.ts:12-19 — KalshiWebSocketConfig { wsUrl, reconnectIntervalMs, watchTimeoutMs }, exposed as KalshiExchangeOptions.websocket at core/src/exchanges/kalshi/index.ts:45.
• core/src/server/exchange-factory.ts:21-25 — export function createExchange(name: string, credentials?: ExchangeCredentials, bearerToken?: string): unknown — the function the sidecar server uses to construct exchange instances (called from core/src/server/app.ts:442 and core/src/server/ws-handler.ts:504) takes no websocket-config parameter at all, and none of its per-exchange new XExchange({...}) call sites pass one through. There is no path from an SDK-supplied websocket config to either real core type.

TypeScript SDK

sdks/typescript/pmxt/ws-client.ts:22-41 — the new WsClientConfig interface actually added by this commit:

/**
 * Tunable WebSocket transport options, surfaced through the exchange
 * constructors (e.g. `new Polymarket({ websocket: { ... } })`).
 */
export interface WsClientConfig {
    wsUrl?: string;
    reconnectInterval?: number;
    pingInterval?: number;
    maxReconnectAttempts?: number;
    connectTimeout?: number;
}

This configures SidecarWsClient (the SDK's own connection to the sidecar's /ws endpoint), not Polymarket's or Kalshi's venue WebSocket feed. None of core's real field names (flushIntervalMs, watcherConfig, userChannelCreds, connectionTimeoutMs, snapshotFallbackMs) exist anywhere in the TS SDK.

Python SDK

Same wrong-layer config, and additionally asymmetric with TypeScript within that wrong layer itself:

• sdks/python/pmxt/client.py:368-370 — docstring for the websocket option only documents wsUrl, reconnectInterval, maxReconnectAttempts.
• sdks/python/pmxt/ws_client.py:154 — _connect_websocket(ws, url, timeout=10) hardcodes the handshake timeout; connectTimeout is accepted in the option dict's type but never read.
• pingInterval has no implementation at all in the Python WS client, vs. full support for all 5 WsClientConfig fields in TypeScript (ws-client.ts:150-215).

Evidence

git show 6d46824 diff only touches ws-client.ts/ws_client.py and the exchange constructors' websocket option handling — it never touches core/src/exchanges/polymarket/websocket.ts, core/src/exchanges/kalshi/websocket.ts, or core/src/server/exchange-factory.ts. Grep confirms none of core's real PolymarketWebSocketConfig/KalshiWebSocketConfig field names appear anywhere in either SDK.

Impact

Users who pass websocket: {...} expecting to configure Polymarket's/Kalshi's actual venue-side WebSocket behavior (e.g. watchTimeoutMs, snapshotFallbackMs, userChannelCreds) are silently tuning an unrelated local transport socket instead — the option is accepted and does something, just not what its name and the venue-specific config in core would imply. #1052 and #1053 remain unresolved; this issue exists to make sure they aren't mistakenly closed as fixed by 6d46824. Additionally, Python's own decoy layer is incomplete relative to TypeScript's (pingInterval unimplemented, connectTimeout unused), a second, smaller asymmetry within the wrong-layer fix itself.

Found by automated Core-to-SDK surface coverage audit