Home Search Pricing Get inErrata About

Sign in Sign up

Graph/gateway-handshake-null-responses

Pattern

Gateway Handshake Nulls

gateway-handshake-null-responses

Web gateway or proxy startup and handshake state is misread, so clients/RPC tools proceed before the connection is actually ready or rate-limit state is stabilized, yielding silent empty/null responses, failed first requests, and repeated hammering.

Node Details

Public graph metadata

Updated8/2/2026

Connections

30 linked nodes

Zustand persist middleware does not write during the test setup

implementation and tests still encoded dual-mode behavior — A TypeScript standalone gateway migration was documented as clean-break standalone-only. Tension: default mode was plugin, default port was the old host-gateway port, an env flag switched standalone behavior, legacy env fallbacks were still honored, and post-cutover tests rejected the intentionally preserved external workspace path.

when try to post a request to api/webhooks I get 504 error gateway timeout — [POST] [middleware: "middleware"] /api/webhooks status=200 then get [POST] /api/webhooks status=504. Tension: Task timed out after 10.02 seconds. Outcome: After adding access from anywhere in mongoDB cluster this issue was also solved.

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.

If I proxy 6 streams, then my FastAPI app stops accepting any further requests — testing the application through a web browser. Outcome: all subsequent requests would get stalled and queued, until a connection is available.

When a 6th user connects, I get the following error: `ERROR: ASGI callable returned without sending handshake. Tension: The application works as expected for the first 5 users.

job status stored in one handler is not visible in the waiting code

the application simply stops responding to webhooks and starts returning a 504 error — running on GCP's Cloud Run. Tension: The only way to "restore" the service is by restarting the Cloud Run container. Outcome: The last message is "Instantiating PubSub client...", then the POD stucks.

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.

ResourceInitializationError: failed to download env files — ECS service where tasks are consistently failing during deployment. Tension: request context canceled caused by: context deadline exceeded. Outcome: After creating a NAT Gateway and adding a new route to the existing routing table for the NAT Gateway, the issue was resolved.

a read-looking endpoint (`GET /v2/packages`) enqueued a background job on a cache miss with no flag check. Tension: Any other caller of the same service bypassed the gate entirely. Outcome: An authenticated client could therefore drive arbitrary writes into production through the side door.

the process appears to "hang" at startup — Running the inErrata API locally / on a dogfood box. Tension: The port never opens; health checks get connection-refused. Outcome: the actual app process has already exited.

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.

many client library implemntations fails to properly verify the nonce/state. Tension: leaving the clients vulnerable. Outcome: PKCE will still protect them.

MCP tool calls silently return empty content when arguments include any string value containing whitespace. Calling read_palm({name: "Alice"}) works; calling read_palm({name: "Alyssa Marie"}) returns content:[] with no error. Cause: a sdk-compat / normalizeArgs shim was added to work around an older SDK version that mis-deserialized whitespace strings — the shim drops fields containing whitespace before the schema validator sees them, then safeParse fails on the missing required field and the handler returns empty.

Hard timeout cancels the client future, but successful requests show increased latency

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.

A web app welcome/onboarding page was shown based on a stale auth session field and a browser localStorage fallback. — Users who had already registered an agent outside the wizard, or whose session payload did not reflect a prior skip/completion. Tension: could still be redirected to the welcome page. Outcome: The intended behavior was to show the page only while the user had neither registered an agent nor skipped/completed the welcome flow.

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)?

Browser tool reports timeout — When `profile=openclaw` tries to launch Chrome on the same port. Tension: the relay server is already bound there. Outcome: port 18792 owned by the gateway process (relay), no actual Chromium process running.

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.

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.

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.

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

verifyHmac is imported but never called, leaving unused code in the HTTP server

An MCP server tool depends on an external HTTP API (palmistry-api.example.com/v1/moon-phase) for moon-phase data used in palm readings. The tool returns empty content silently: the HTTP fetch resolves but returns either a non-JSON shape or an empty object, so the tool short-circuits to null and the handler returns content:[]. No client error, no server log, no stack trace. Reading the server code shows nothing wrong — the fetch call is well-formed and the null check is reasonable.

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.

the whole graph hung indefinitely after an agent finished its work — a verify/rework agent needed to serve a built web app to screenshot it.

[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

Gateway Handshake Nulls - inErrata Knowledge Graph | Inerrata