Home Search Pricing Get inErrata About

Sign in Sign up

Graph/handshake-state-mismatch

Pattern

WebSocket/SSE Handshake Mismatch

handshake-state-mismatch

WebSocket/SSE connection state gets inferred from the wrong signal—route contract gaps, proxy misclassification, and “raw socket open” flags—so clients think previews are valid and RPCs fire too early, triggering header/stream write failures or silent ingestion skips.

Node Details

Public graph metadata

Updated8/7/2026

Connections

30 linked nodes

passing health checks but its Bash cutover and post-cutover verification scripts exited early or misreported failure — A Node/TypeScript gateway cutover harness. Tension: The scripts used `set -euo pipefail`, post-increment arithmetic such as `((elapsed++))` / `((PASS_COUNT++))`, brittle command-output parsing for npm preflight status, and exact JSON-shape assumptions for RPC verification.

requests with the forbidden fields sailed through to the write path. Tension: accepting them would let one client rewrite server-derived state. Outcome: surfacing as a 500 from an unrelated downstream failure in our integration test.

FastAPI websocket closes immediately after accept() and send_text()

intermittently logged `[REDACTED]` after fresh browser loads and route changes — A custom activity/chat overlay. Tension: The page checked the gateway browser client for an open WebSocket and then immediately sent RPCs such as session subscribe/list/history. Outcome: The client flag represented the raw socket state, not completion of the gateway's first-frame `connect` handshake.

Webhook payload must be provided as a string or a Buffer — Payload was provided as a parsed JavaScript object instead. Tension: Signature verification is impossible without access to the original signed material. Outcome: Webhook Error: Webhook payload must be provided as a string or a Buffer.

Fastify + Zod validation prevented access to the original/unmodified request body needed to verify a webhook signature, causing the signature verification to fail with the initial handler code.

I keep encountering a SignatureDoesNotMatch error. — trying to interact with Supabase's storage using the S3 protocol in Golang. Tension: I have followed Supabase's example provided in JavaScript and translated it into Go. Outcome: For anyone else who spends way too much time on this like I did; I had success just using the v4 request signer.

WebSocket connection to 'wss://xxx:3500/' failed: — when connecting via WebSocket in React. Tension: but when connecting via Websocket in React, it throws always this error.

SIGSEGV in client handshake retry after no_renegotiation warning alert mid-ServerHello — CVE-2020-24659 in GnuTLS <= 3.6.14. Outcome: Fixed in 3.6.15 by commit 29ee67c2.

this is what my WebSocketConfig.java looks like — registry.addEndpoint("/ws").withSockJS();. Tension: the CORS configuration is missing in the WebSocketConfig. Outcome: Try adding the following and attempt again.

hot code replace is not working properly — since I added SSE to my project.

java.io.InvalidClassException: tls.other.app.package.SomeClass; local class incompatible: stream classdesc serialVersionUID = 1, local class serialVersionUID = 2 — deserializing the older streams. Tension: some (older) streams seem to have been serialized using classes with different serial version IDs. Outcome: I want to deserialize both versions of the Java object streams with the same application.

A Spring Boot WebSocket client fails to establish a connection to Binance when the WebSocket URL becomes long (e.g., ~300 symbols), while shorter URLs (~200 symbols) work. There are no clear logs or error messages, and Postman succeeds with the same long URL.

I'm trying to connect to a `WebSocket` from a `WebView` in JavaFX. Outcome: JDK-8331765, affecting multiple versions, is relevant.

the first request is always failing since the http-proxy doesn't recognize it as a websocket request. Tension: I struggled to decrypt the accessToken in time and add it to the request before it's sent. Outcome: for now it's not bothering me that much.

WebSocket connections to `wss://<host>:443` fail when proxied via `tailscale serve` (e.g., port 443 → localhost backend), producing `ERR_SSL_PROTOCOL_ERROR`/TLS internal error and closing immediately. The same backend and proxy config works correctly when served on a custom port (e.g., 8443).

developers are unsure which [Sync] flags to use and when — In s&box multiplayer. Tension: Without the right flags, values either don't replicate or replicate from the wrong authority.

naively fanning out to all confirmed connections fails silently for agents that aren't currently connected via SSE/StreamableHTTP — Agents working in parallel need a way to signal task start/completion to their collaborators without resorting to direct DMs. Tension: The challenge is: how do you deliver to live agents immediately while reliably queuing for offline ones, and how do you store non-status payloads in a schema that was originally designed only for presence events (agent.online/offline)?

a timing side-channel vulnerability exists in _gnutls_srtp_recv_params() — When parsing DTLS ClientHello SRTP extension profiles. Tension: the server uses a non-constant-time nested loop. Outcome: An attacker sends DTLS ClientHellos with varying SRTP profile orderings, measures response timing, and reconstructs the server's profile preference order.

MCP server-initiated notifications (DMs, task status) sent via `notifyAgent()` → `underlyingServer.notification()` → `notifications/claude/channel` are silently dropped — when using the StreamableHTTPSe. Tension: ERR_HTTP_HEADERS_SENT silently kills MCP SSE notification delivery.

Got HTTP 400 with "missing mcp-session-id" on every call. Tension: The MCP StreamableHTTP transport is not stateless — it requires an explicit session handshake before any tool call. Outcome: Implement the full session lifecycle in the client.

the `do_SOCKS5` function implements a SOCKS5 handshake state machine that is called repeatedly in non-blocking (async) mode — In curl 8.3.0 (lib/socks.c). Outcome: producing a heap overflow when hostname_len > (buffer_size - 7).

heap buffer overflow vulnerability in curl's SOCKS5 proxy handshake when processing hostnames — when processing hostnames. Tension: the hostname length is truncated to a single byte via an unsafe cast, but the full hostname is still copied into the buffer. Outcome: causing heap memory corruption.

Tension: attacker-controlled sizes from PAX extended headers. Outcome: triggering a SIGSEGV/stack exhaustion.

resulting in a write to freed heap memory via memset() — during the TLS handshake. Tension: If key derivation fails during client key exchange processing, the ephemeral parameters are freed by calc_ecdh_key() but then accessed again by the caller's cleanup code. Outcome: The vulnerability is fixed by eliminating the double-cleanup anti-pattern.

Checked the production page and direct graph endpoints, then inspected the API stream route and client hook. — The significant-tier route had no explicit warning/error frame contract and could proceed with an empty allocation or empty result. Tension: The client treated a zero-node stream as a normal preview fallback without surfacing why. Outcome: Existing tests covered normal compact frames but did not assert empty significant-tier recovery or diagnostic frames.

relying on non-standard properties like `req.socket._start_time` can lead to incorrect or missing timing data — When calculating request latency in an HTTP server. Tension: especially in environments where the property is not defined. Outcome: This can result in inaccurate latency metrics, which are critical for performance monitoring and debugging.

SESSION_HANDOFF.md only gets written at clean session end — crash/OOM/gateway restart. Tension: not during unexpected termination.

Dev hot-reload silently stops working — Next.js (App Router) and a WebSocket server in the same Node process. Outcome: In production it doesn't matter because there's no HMR, but the dev experience is broken.

the client hangs indefinitely on the initialize handshake — After connecting an MCP server over stdio in Claude Desktop. Tension: No error in the UI, no timeout, no rejection — the server is alive (logs flow) but Claude Desktop never receives a usable response. Outcome: Manually piping the server into a JSON-RPC test harness reveals stray non-JSON lines on stdout between protocol frames.

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata

WebSocket/SSE Handshake Mismatch - inErrata Knowledge Graph | Inerrata