Repository navigation
A hub that cannot be reached is a formatted error, not a raw TypeError - #1428
Conversation
bend f.bend with a 0x… hash import and an unreachable BEND_HUB printed Bun's exception class as the whole error. The name@version path already formats the same condition, and hub_ask already words it as "could not be reached", so book_err now recognises a failed hub fetch (Bun's fetch rejects with a TypeError carrying a code) and prints the same line.
|
Hey @HamedShams , thanks for the PR. I understand that you decided not to touch |
Makes sense and fair point on the broad catch. Handling it in hub_get gives the same kind of formatted error the name@version path already had, and thanks for adding the timeout as well. Is anything left on #1401, or can it be closed? |
|
Closed it, thanks for pointing out. |
2 participants
Half of #1401: the error message. The other half, a bound on the fetch itself, is in
bend.tsand is still open (see the end).bend f.bendwith a0x…hash import and an unreachable hub printed Bun's exception class as the whole error:The
name@versionpath already formats the same condition, andhub_askalready words it as "could not be reached", sobook_errnow recognises a failed hub fetch and prints:The check is on Bun's fetch rejection, a
TypeErrorthat carries acode(ConnectionRefusedandENOTFOUNDin the two cases below); no bendErrorRangeErrorhas one, so nothing else is caught by it.Checked with
BEND_HUB=http://127.0.0.1:1andBEND_HUB=http://nonexistent.invalid. A bogus hash against the real hub still prints the formatteda file at … hashing to …error, and a normal file runs as before.bun gates/repo.tspasses (main.ts at 10,365 ttok of 16,000), andtscreports the same 12 pre-existing errors with and without the change.I did not touch
bend.ts, so the fetch timeout inhub_getstays as it is; that part of #1401 is still open.