From 98e63288701d433ae7eb2e8b53daa00ee52c3057 Mon Sep 17 00:00:00 2001 From: Chad Miller Date: Mon, 24 Aug 2026 23:36:01 -0700 Subject: [PATCH] fix: point the indexer at the Jetstream instance Railway can reach MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since around 8/19 the us-east name has answered 503 to anything leaving Railway — haproxy's "No server is available to handle this request", on every path, /status included — while the same IP answers 200 from a laptop. Both sides resolve 108.179.138.19, so it is the load balancer refusing by where the request came from, not DNS and not a network black hole. Eight checks in a row from each side: 503 every time from the container, 200 every time from outside. That is what froze the cursor in the first place, and the stale cursor then became a second trap that would have held even after the host came back. alpha.80 handles that half; this handles the half that is not ours to fix. us-west is healthy from the container — 1145 events in eight seconds on the same subscribe — and is the host the Jetstream docs use in their own example. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01VzBpc8vV143n7G5cm65yNm --- hatk.config.ts | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/hatk.config.ts b/hatk.config.ts index 0e3cfa8..7b2d2c4 100644 --- a/hatk.config.ts +++ b/hatk.config.ts @@ -46,7 +46,14 @@ export default defineConfig({ // Jetstream filters server-side, so we stop decoding the whole network to // find social.grain.*. Prod only — the local PDS has no Jetstream in front // of it. `relay` is still required: backfill resolves repos through it. - jetstream: isProd ? { url: "wss://jetstream.us-east.bsky.network" } : null, + // + // us-west, not us-east: since around 2026-08-19 the us-east name answers 503 + // ("No server is available", haproxy with no backend) on every path — /status + // included — for requests leaving Railway, while the same IP answers 200 from + // elsewhere. So it reads as healthy from a laptop and is unreachable from the + // one network that matters, which is why this took a while to see. us-west is + // what the Jetstream docs use in their own example. + jetstream: isProd ? { url: "wss://jetstream.us-west.bsky.network" } : null, plc: isProd ? "https://plc.directory" : "http://localhost:2582", port: 3000, cdn: isProd -- 2.51.2