fix: name the unreachable host when a scaffold fetch fails - #195
Merged
Conversation
`seamless init` makes three remote reads (the template registry, the templates archive, and the auth server's .env.example). A connection-level failure in any of them rejected with a bare `TypeError: fetch failed`, which reached the top-level handler as "Error: fetch failed" and named neither the host nor which read had failed. Route all three through a `fetchRemote` helper that reports the URL, what the CLI wanted from it, and the network as the likely cause. Non-ok responses keep their existing messages.
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
seamless initreported a bareError: fetch failedwhenever one of its network reads wasrejected at the connection level, giving no way to tell what was unreachable:
There are three remote reads on the scaffold path, and the message was identical for all three:
openRemoteSourceinsrc/core/templates.ts, fetchingregistry.jsonensureArchivein the same file, downloading the templates.zipfetchEnvExampleinsrc/core/fetch.ts, fetching the auth server's.env.exampleEach already handles a non-ok HTTP response with a message naming the status and the URL. What
was missing is the connection-level rejection:
fetchthrowsTypeError: fetch failedand thatpropagated untouched to the top-level handler in
src/index.ts.This showed up repeatedly while building the scaffold smoke job (#192).
Change
A
fetchRemote(url, purpose)helper insrc/core/fetch.tswraps the GET and turns aconnection-level rejection into a message naming the URL, what the CLI wanted from it, and the
network as the likely cause, in the style
loginFlow.ts'srequest()already uses. The originalerror is kept as the thrown error's
cause. All three call sites go through it. Non-ok responseskeep the messages they had.
Verification
npm run buildandnpm testpass (979 tests). New unit tests cover all three messages, and eachpath was also exercised end to end against the built CLI with only the failing host blocked:
Changeset: patch.