Relay never recovers from a restarted Redis: EVALSHA without an EVAL fallback leaves it serving nothing #1002

What happened

On 2026-10-31 a production relay on ghcr.io/cameri/nostream (v3.0.0, Node 24.20.0) was left unable to answer a single REQ after its Redis cache was restarted. The containers were healthy, the HTTP endpoint answered 200, and every websocket upgrade succeeded — then the socket said nothing, forever. The client sees a hang, not an error.

The log, in order:

uncaught error: Error: connect ECONNREFUSED 172.18.0.2:6379
web-socket-adapter: unable to handle message: [ErrorReply: NOSCRIPT No matching script. Please use EVAL.]
uncaught error: [ErrorReply: NOSCRIPT No matching script. Please use EVAL.]

The first line is the swap itself and is expected. The NOSCRIPT lines never stop: the relay keeps calling EVALSHA against a script cache that a restarted Redis no longer has, and there is no fallback path. Restarting the relay re-registers the scripts and it recovers immediately.

Why it matters beyond this one host

Restarting a cache is routine: an upgrade, a memory-driven restart, a failover, a docker compose up -d cache that recreates only the cache container. nostream's own compose makes the trap easy to hit, because the cache and the relay are separate services and up -d recreates only the one whose definition changed — so the relay is left running against a cache that forgot its scripts.

The failure is also self-concealing. HTTP health checks pass, the process is up, and nothing in the container is unhealthy; only a client that sends REQ sees it. On the host where this was found, the relay had been answering 200 for minutes while serving zero events.

Expected

A NOSCRIPT reply should be handled the way any Redis client binding handles it: re-send the same script body with EVAL (ioredis does this automatically for commands defined through defineCommand, which is the usual reason this is invisible everywhere else). The relay should never enter a state where it cannot recover from a flushed script cache without a process restart.

How it was reproduced

docker compose up -d nostream-cache     # recreate only the cache
# relay stays up; https://<relay>/ still answers 200
# a websocket REQ returns nothing, and the log repeats NOSCRIPT
sudo docker restart nostream            # recovers

Notes

• Worth checking whether the scripts are issued through defineCommand (which caches script bodies client-side and retries with EVAL) or through a raw evalsha, and whether the error is being swallowed by a worker's uncaught error handler rather than surfacing to the connection.
• A second, smaller gap observed in the same incident: connect ECONNREFUSED is logged as uncaught error at level 50 two or three times before the client reconnects. The reconnect works, but an uncaught error in a worker is the wrong classification for a transient dependency.