fix(dashboard): resolve API origin correctly in docker-compose#7
Merged
Merged
Conversation
Dashboard SSR fetches (e.g. GET /health/env) resolved the API origin from a static runtime-target table defaulting to http://localhost:4000. Inside the dashboard container that never reaches the api container, causing "Cannot resolve deployment info ... ECONNREFUSED" on every docker compose up. INTERNAL_API_URL already existed as an override but was gated behind NEXT_PUBLIC_API_PROXY=true, a NEXT_PUBLIC_* build-time flag the Dockerfile never sets. Loosen getServerApiBaseUrl to honor INTERNAL_API_URL unconditionally for server-side requests, and set it in docker-compose.yml to the in-cluster DNS name (http://api:4000), matching the pattern already used for api's own DATABASE_URL/REDIS_URL overrides. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
Author
|
The dashboard wasn't really loading for me after docker compose up without this fix. |
Member
|
Reviewed it - fix looks right, http://api:4000 matches the compose service and the SSR-direct routing makes sense. Two things first:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
GET /health/env) always resolved the API origin from a static runtime-target table, which defaults tohttp://localhost:4000. Inside the dashboard container that never reaches theapicontainer, so everydocker compose upfails withCannot resolve deployment info: GET /health/env is unreachable ... ECONNREFUSED.INTERNAL_API_URLalready existed as an override inapps/dashboard/src/lib/server/api.ts, but was only honored whenNEXT_PUBLIC_API_PROXY=true— aNEXT_PUBLIC_*build-time flag the dashboardDockerfilenever sets, so the override was effectively dead code in this deployment path.getServerApiBaseUrlto honorINTERNAL_API_URLunconditionally for server-side requests (browser-side resolution is untouched), and set it indocker-compose.ymlto the in-cluster DNS name (http://api:4000) for thedashboardservice — matching the same pattern already used forapi's ownDATABASE_URL/REDIS_URLoverrides.Test plan
docker compose up -d --build dashboard— dashboard boots clean, noECONNREFUSED/health/enverror in logscurl http://localhost:3001returns a normal redirect instead of the fatal error pageOPENSHIP_LOCAL_API_URLand proxy-mode (NEXT_PUBLIC_API_PROXY=true) paths, which are unaffected in code review but worth a sanity check