Repository navigation
[agent-cli] The bundle check sends its HEAD to the dev server it was given, never to the tunnel host (llp/0010 §Other gates) - #197
Merged
Conversation
vonovak
force-pushed
the
vonovak/fix-bundle-check-local
branch
from
October 23, 2026 22:22
e1efb4c to
e101593
Compare
…given, never to the tunnel host (llp/0010 §Other gates)
On an EAS Simulator session every runtime read (runtime:tree, tap, type,
reload, smoke) answered "No target found" although Metro listed the app
(dogfood night 3, N3-03). The entry-bundle check HEADed the manifest's
launchAsset.url, which under --tunnel names the tunnel host, so the HEAD
went out through the Expo tunnel and back in.
Measured on a local `expo start --tunnel` with no device (Expo CLI
58.1.13, @expo/ws-tunnel 2.0.1): the relay forwards that HEAD to the
local tunnel client as a GET, aborts it once the headers are out, and the
client answers the abort with a RequestAbort message the relay rejects
("[Server Disconnect] Invalid message type: 2", close 1007). The relay
then drops the whole tunnel websocket and every websocket proxied over
it: the app's inspector socket, HMR, /message. The app reconnects later;
until then the target is listed and does not answer the probe.
The check now keeps the path and query the manifest or the web page
names and sends the HEAD to the dev server it was given. bundle.url is
that local URL. llp/0010 states the rule; llp/0022 says the live-cloud
suite proves the public origin elsewhere.
Red before: cloud-simulator-test "restarts the app and then deep-links
the route, and never closes it" (bundle checked: false on main),
bundleCheck-test "should send the HEAD to the dev server given a launch
asset on the tunnel host" and "... when the page names another host".
Live, no device: with main's code the CLI's own check closed two
websockets held through the tunnel (1007); with this change, four runs
left them open and the tunnel log showed no bundle request.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
vonovak
changed the title
vonovak
force-pushed
the
vonovak/fix-bundle-check-local
branch
from
October 27, 2026 07:15
e101593 to
0152521
Compare
vonovak
marked this pull request as ready for review
October 27, 2026 07:54
Kudo
approved these changes
Oct 27, 2026
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.
Problem
On an EAS Simulator session every runtime read (
runtime:tree,runtime:tap,runtime:type,runtime:reload,smoke) answered "No target found" although Metro listed the app (dogfood night 3, N3-03). The entry-bundle check that runs before each of them sent its HEAD to the manifest'slaunchAsset.url. Under--tunnelthat URL names the tunnel host, so the HEAD went out through the Expo tunnel and back in.That round trip drops the tunnel. Measured on a local
expo start --tunnelwith no device (Expo CLI 58.1.13,@expo/ws-tunnel2.0.1): the relay forwards the HEAD to the local tunnel client as a GET, aborts it once the headers are out, and the client answers the abort with a message the relay rejects ([Server Disconnect] Invalid message type: 2, close 1007). The relay then closes the whole tunnel websocket and every websocket proxied over it: the app's inspector socket, HMR,/message. The app reconnects on its own schedule; until then the target is listed and does not answer the probe. A full GET of the bundle, a HEAD of/statusand a HEAD on127.0.0.1do no harm.Fix
The check keeps the path and query the manifest (or the web page) names and sends the HEAD to the dev server it was given.
bundle.urlis that local URL. llp/0010 §Other gates states the rule and the reason. The live-cloud suite now asserts thatbundle.urlis local; the public origin stays proven by its curl of<origin>/statusand by thenavigateassertions, and llp/0022 says so. Known limit: a caller that names the tunnel itself with--dev-server-url https://<tunnel>still sends the HEAD through it.Red before:
cloud-simulator-test"restarts the app and then deep-links the route, and never closes it" (the stub's manifest names a tunnel host; the check reportedchecked: false) andbundleCheck-test"should send the HEAD to the dev server given a launch asset on the tunnel host".Live check, no device, one tunnel session: the positive control with the old code closed two websockets held through the tunnel (1007); four runs with the fix left them open for 25 s, a new websocket opened after each, the check reported a
127.0.0.1URL, and the tunnel log showed no bundle request.One thing to watch in the live-cloud job: the app's inspector socket no longer drops and reconnects during the check, so
runtime:reload'sverifiedBylabel can shift and the reload can take longer; the assertion accepts four labels.🤖 Generated with Claude Code