Repository navigation
fix(preview): count the app's own 403/404 as routed - #57
Merged
Merged
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
get_url/get_port_url treated every 403 or 404 as "not routed yet", so an app that answers 404 or 403 at its root (an API-only server, a sign-in page) made the wait run out its whole timeout and raise, though the URL was live. The edge marks every response the app produced with an upstream header and never marks its own refusals, so a marked 403/404 now counts as routed. The async client matches.
mayur-tolexo
force-pushed
the
fix/preview-wait-app-404
branch
from
October 17, 2026 05:42
0984a0d to
7e32281
Compare
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.
Why
get_port_url/get_urlwait until a fresh preview URL is routed, and they took any 403 or 404 to mean "not yet". That is right for the edge's own answers in the first seconds after a port is exposed, but an app can answer 403 or 404 at its root too: an API-only server with no/route, or a sign-in-gated page. Against such an app the wait ran out its whole timeout (60 s by default) and then raised, even though the URL had been live all along.What
The edge adds an upstream header to every response the app produced and never to its own refusals. A 403 or 404 carrying that header now counts as routed; one without it keeps the wait going. Nothing else changes: other statuses still count as routed, and a connection error still means not yet. The async client matches. A patch changeset is included.
Example
A FastAPI app with only
GET /apiexposed on port 3000:sandbox.get_url(3000)used to raise "was not routable"; it now returns the URL as soon as the route is live.Testing: new tests for the edge-vs-app rule, sync and async; the existing not-routed and timeout tests still pass.
ruff check,ruff format --check,mypyandpytestpass.The JS SDK gets the same change in NeevCloudAI/neev-sdk-js#71.