fix(routing): fall back to container IP when loopback port is not published - #508
Closed
santhiprakash wants to merge 1 commit into
Closed
fix(routing): fall back to container IP when loopback port is not published#508santhiprakash wants to merge 1 commit into
santhiprakash wants to merge 1 commit into
Conversation
…lished Same-server migrations that attach the running container in place (reuse) never publish a 127.0.0.1 host port, so the default "Auto → loopback-port" strategy left the app unreachable through its custom domain. The edge could not reach the container because it had no loopback binding to dial. Make the live route-apply paths inspect the container first, then fall back to the container's bridge/host IP when no loopback host port is bound: - resolveUpstreamUrl now falls through from a loopback host port to the container IP when hostPort is absent. - applyProjectRouting resolves a live upstream per service_deployment row, using getContainerInfo for the current host port and getContainerIp as the fallback. - service.service updateService does the same live resolution when publishing or editing a service route, so migrated domains register with the correct container IP target instead of a missing loopback port. Adds focused tests for the fallback in upstream-url and routing-apply.
Contributor
Author
|
Closing — upstream main now resolves route upstreams from the live container (resolveLiveUpstreamUrl in apps/api/src/modules/domains/routing-apply.service.ts) so workloads without a published loopback port route at their container IP, which is what this PR implemented for #506. |
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
1 participant
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
Fixes #506.
Same-server migrations that attach the running container in place (reuse) never publish a
127.0.0.1host port, so the default Auto → loopback-port strategy left the app unreachable through its custom domain. The edge had no loopback binding to dial.Change
Make the live route-apply paths inspect the container first, then fall back to the container's bridge/host IP when no loopback host port is bound:
resolveUpstreamUrlnow falls through from a loopback host port to the container IP whenhostPortis absent.applyProjectRoutingresolves a live upstream perservice_deploymentrow, usinggetContainerInfofor the current host port andgetContainerIpas the fallback.service.serviceupdateServicedoes the same live resolution when publishing or editing a service route, so migrated domains register with the correct container-IP target instead of a missing loopback port.Test plan
apps/api/src/lib/upstream-url.test.ts– unit tests forbuildUpstreamUrlandresolveUpstreamUrl, including the loopback → container-IP fallback.apps/api/src/modules/domains/routing-apply.service.test.ts– tests thatapplyProjectRoutingfalls back to the container IP when the migrated container has no loopback host port, uses the live loopback port when present, and still falls back when live inspection fails.bun run lint(tsc --noEmit) passes.bun vitest run src/modules/migrationpasses.