Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

fetch/XHR transport failures and unhandled rejections lose all diagnostic fidelity before reaching the embedding app

Ouverte
  • Quelque chose ne va pas ?
#196 0 commentaires 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@bkaradzic-microsoft y travaille déjà.

Depuis le 16/6/2026.

  • #204 par @bkaradzic-microsoft — fermée sans fusion

Évaluation

Cette issue n'a pas encore été évaluée.

Description

Applications embedding Babylon Native depend on field crash reports for ongoing maintenance, and today a fetch()/XMLHttpRequest failure arrives there with no usable signal: DNS failure, connection refused, TLS rejection, proxy auth failure, server outage, and a missing bundled app:/// asset are all byte-identical, and an un-caught rejection never reaches the host (BN) application at all. This issue tracks the chain of fixes; each hop is independently shippable.

The chain (where fidelity is lost today)

  1. UrlLib swallows transport errors at the source. ✅ Fixed by BabylonJS/UrlLib#31 (open): the Apple backend discarded the NSError (long-standing in-code TODO) and the curl backend caught and dropped its own failure, leaving only StatusCode() == 0. UrlLib now exposes ErrorString() / ErrorSymbol() / ErrorCode(), normalized as "<domain>:<symbol>(<code>): <detail>" (e.g. curl:CURLE_COULDNT_RESOLVE_HOST(6): ..., nsurl:NSURLErrorCannotConnectToHost(-1004): ..., urllib:AppResourceNotFound(0): ...) — stable tokens for observability-pipeline filtering, purely additive (status-0 contract unchanged).

  2. The fetch polyfill flattens every transport failure to a constant string. Fetch.cpp throws std::runtime_error{"fetch: network request failed"}, discarding result.error() and the URL/method context it has in scope; the rejection surfaces as a plain Error (browsers/Node/Bun: TypeError) with no cause, no code, and a .stack snapshotted inside the scheduler tick — i.e. zero user frames. Proposed shape, once the UrlLib pin includes #31:

    • reject with a TypeError whose message is stable ("fetch failed" style — keeps crash-report grouping intact), carrying the variable detail as properties: cause (message from ErrorString()), code (ErrorSymbol()), url;
    • capture the JS call-site stack synchronously inside fetch() before SendAsync() (create the rejection Error, or a stack carrier, while user frames are still on the stack — the undici approach) so crash reports can attribute the failing call;
    • same treatment for XMLHttpRequest's error path.

  3. Unhandled promise rejections never reach UnhandledExceptionHandler. AppRuntime::Dispatch only catches synchronous Napi::Error throws from dispatched callbacks; no engine-level rejection tracker is wired anywhere in Core, so a fire-and-forget fetch() failure (or a throw inside any .then) vanishes silently — the embedder's handler never fires and the process exits 0. Proposal: an opt-in AppRuntime::Options handler (or routing into the existing one) fed per engine — Isolate::SetPromiseRejectCallback (V8), JsSetHostPromiseRejectionTracker (Chakra), JSGlobalContextSetUnhandledRejectionCallback (JavaScriptCore), and the JSI tracker — the per-engine seams already exist as AppRuntime_{V8,Chakra,JavaScriptCore,JSI}.cpp.

  4. fetch ignores init.signal. The implementation passes arcana::cancellation::none() for both continuations, so abort never rejects (AbortError) and never cancels the transport. Two prerequisites: UrlRequest::Abort() currently only cancels the Windows backend (the curl/NSURLSession backends never observe m_cancellationSource), and the AbortSignal polyfill predates the modern spec (no reason/throwIfAborted(), writable aborted). Worth sequencing with BabylonJS/BabylonNative#1708, which installs AbortController globally in the Playground — after which library feature-detection passes while signals silently no-op, and user-initiated cancellations become indistinguishable from network failures in telemetry.

Validation

Beyond unit tests per hop (UrlLib#31 already ships offline-deterministic transport-failure tests + CI), the highest-value conformance ports for this area: the WPT fetch/api/abort/general.any.js core cases (pre-aborted/mid-flight/post-settle, signal.reason), undici's fetch failed-with-cause assertions from test/fetch/client-fetch.js, a four-way failure-shape bank (refused / NXDOMAIN / bad TLS / missing local asset must be distinguishable and TypeError-shaped), and a native-side test that an unhandled rejection actually reaches the host handler.

Happy to submit PRs for hops 2–4 individually (2 is unblocked as soon as the UrlLib pin can include #31; 3 and 4 are independent).

Related: #188 (fetch polyfill), #195 (statusText — same UrlLib-consumption pattern hop 2 would follow), BabylonJS/BabylonNative#1707.

Langage dominant
C++
Étoiles
22
Forks
23
Merge moyen
6 h 17 min
PR mergées (30 j)
4

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de BabylonJS/JsRuntimeHost

Toutes les issues de BabylonJS/JsRuntimeHost

Issues similaires

Plus d'issues C++

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.