Why do you want to contribute?
I'd like to fix #3643 (env vars declared but never consumed).
After investigating the issue, I found that 18 different *_REDIS_READER_HOST / *_REDIS_READER_PORT env-var pairs are declared in apps/webapp/app/env.server.ts but none of them are consumed anywhere in the repo. The issue title flags 6 of them but the problem is broader.
The original issue author also flagged the design itself as open ("would be useful to know if there's an intended design (e.g. is the eventual goal cluster-mode + read-from-replicas, or twin-client?)"). Rather than invent a new Redis reader/writer split pattern across ~10 files (some of which — Upstash Ratelimit, GCRA limiter Lua eval — can't be cleanly split read/write at all), my proposal is:
Delete the 36 unused declarations (18 host + 18 port). The global REDIS_READER_HOST / REDIS_READER_PORT would stay since those are documented in docs/self-hosting/env/webapp.mdx. None of the per-subsystem vars are documented anywhere, and z.object({...}).parse() strips unknown keys silently, so self-hosters who set them today get a silent no-op — exactly the same behavior as after this PR. The change is purely cosmetic to operators and removes maintenance burden. If maintainers want a real reader/writer split, that's a separate RFC and a separate PR.
Diff is ~50 lines, mechanically verifiable, zero behavior change. Would add a .server-changes/ entry per repo convention and run pnpm run typecheck --filter webapp.
If maintainers prefer a different approach (e.g. actually wire the vars up with some design pattern), happy to adjust — flagging that here before writing a PR.
Minor: the issue lists TASK_META_CACHE_REDIS_READER_HOST but that var doesn't exist — only the writer variant (TASK_META_CACHE_REDIS_HOST) is declared. Will note this in the PR.
Prior contributions or relevant experience
GitHub: https://github.com/abdulmunimj — TypeScript / Node / Remix background; comfortable in monorepos. Happy to keep the scope tight to what's described above.
Why do you want to contribute?
I'd like to fix #3643 (env vars declared but never consumed).
After investigating the issue, I found that 18 different
*_REDIS_READER_HOST/*_REDIS_READER_PORTenv-var pairs are declared inapps/webapp/app/env.server.tsbut none of them are consumed anywhere in the repo. The issue title flags 6 of them but the problem is broader.The original issue author also flagged the design itself as open ("would be useful to know if there's an intended design (e.g. is the eventual goal cluster-mode + read-from-replicas, or twin-client?)"). Rather than invent a new Redis reader/writer split pattern across ~10 files (some of which — Upstash Ratelimit, GCRA limiter Lua eval — can't be cleanly split read/write at all), my proposal is:
Delete the 36 unused declarations (18 host + 18 port). The global
REDIS_READER_HOST/REDIS_READER_PORTwould stay since those are documented indocs/self-hosting/env/webapp.mdx. None of the per-subsystem vars are documented anywhere, andz.object({...}).parse()strips unknown keys silently, so self-hosters who set them today get a silent no-op — exactly the same behavior as after this PR. The change is purely cosmetic to operators and removes maintenance burden. If maintainers want a real reader/writer split, that's a separate RFC and a separate PR.Diff is ~50 lines, mechanically verifiable, zero behavior change. Would add a
.server-changes/entry per repo convention and runpnpm run typecheck --filter webapp.If maintainers prefer a different approach (e.g. actually wire the vars up with some design pattern), happy to adjust — flagging that here before writing a PR.
Minor: the issue lists
TASK_META_CACHE_REDIS_READER_HOSTbut that var doesn't exist — only the writer variant (TASK_META_CACHE_REDIS_HOST) is declared. Will note this in the PR.Prior contributions or relevant experience
GitHub: https://github.com/abdulmunimj — TypeScript / Node / Remix background; comfortable in monorepos. Happy to keep the scope tight to what's described above.