v1.19.27#907
Conversation
Federation lookups broke after the stellar-sdk v16 upgrade with
"stellar.toml does not contain FEDERATION_SERVER field".
SDK v16 routes stellar.toml/federation requests (which set
maxContentLength/maxRedirects) through feaxios' bounded-fetch adapter,
which reads the body exclusively via `response.body.getReader()`. React
Native's fetch (whatwg-fetch) implements text()/arrayBuffer()/json() but
never exposes the streaming `Response.body` getter, so the adapter read
an empty buffer, every stellar.toml parsed to `{}`, and FEDERATION_SERVER
came back undefined.
Add a Response.body polyfill that backs the missing getter with the
arrayBuffer() RN does support, exposed as a single-chunk ReadableStream.
It is guarded (no-ops where Response.body already exists) and memoized per
response. Wired into bootstrap.js alongside the existing SDK polyfills, so
it loads before any SDK network call. Fixes federation and all other SDK
bounded-fetch paths, not just the symptom.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a793306fee
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| export const createResponseBodyStream = ( | ||
| response: ArrayBufferBody, | ||
| ): ReadableStream<Uint8Array> => { | ||
| const bodyPromise = response.arrayBuffer(); |
There was a problem hiding this comment.
Defer reading until the stream is consumed
When callers only probe or cancel response.body, this starts arrayBuffer() immediately, before any reader actually reads from the stream. That affects existing early-error paths such as fetchMetadataJson's redirect/non-OK/oversized-Content-Length branches, which call response.body?.cancel?.() to discard the response; with this getter installed, those paths now begin buffering/converting the body they are trying to reject, so a large error/redirect response can allocate the full body before throwing. Deferring arrayBuffer() until the first pull/read, or making cancellation before the first read avoid starting it, would preserve the fail-fast behavior.
Useful? React with 👍 / 👎.
|
iOS Simulator preview build is ready: https://github.com/stellar/freighter-mobile/releases/tag/untagged-56ed10f3063581d659c7 (SDF collaborators only — install instructions in the release description) |
Release Changes