Tests:

• are large files still supported (restore a large file)
• are empty files replaced with "\n" (restore a 0-byte file)

are large files still supported

Meh

• If the requested file's size is:
  • 1 MB or smaller: All features of this endpoint are supported.
  • Between 1-100 MB: Only the raw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be "none". To get the contents of these larger files, use the raw media type.
  • Greater than 100 MB: This endpoint is not supported.

The API itself returns a valid string. The issue must be in how we're processing or storing it

@copilot take a look. Don't commit any changes, just explain what could be the issue and how it can be fixed

@copilot take a look. Don't commit any changes, just explain what could be the issue and how it can be fixed

Root cause: api.v3() always reads responses as text

In api.tsx line 118: const textContent = await response.text(). This means there's no binary-safe path. The original code used raw media type + json: false, but response.text() decodes binary bytes as UTF-8, corrupting non-UTF-8 binary content. That's the original issue this PR was trying to fix.

How to fix:

The object approach works for files ≤1MB (returns base64 directly), but fails for larger files. The proper fix is to add binary response support to api.v3() so we can fetch raw content as an ArrayBuffer and convert to base64 correctly:

1. Add a binary: true option to api.v3() that uses response.arrayBuffer() instead of response.text()
2. In getFile(), use Accept: application/vnd.github.raw with binary: true
3. Convert the result: uint8ArrayToBase64(new Uint8Array(arrayBuffer)) from uint8array-extras

This would handle both binary files and large files (up to 100MB) correctly, since the raw binary data never goes through text decoding.

(Note: the empty/0-byte file issue with !file is pre-existing — the original code had the same problem since stringToBase64("") returns "" which is also falsy.)

• Add a binary: true option to api.v3() that uses response.arrayBuffer() instead of response.text()

@fregante do we need that option? I think base64 would be more useful

Limiting the whole feature to <1MB is definitely a downgrade, so that's out of the question. A common file I restore is package-lock.json, which is too often very large (monorepos and such)

As for the binary option, it would be ok as long as we don't have to manually toggle between two fetching modes in this feature. I think that would introduce many points of failure. What do you think?

26.3.21 can't discard new files (it throws a 404 error) and changes to 0-byte files (it deletes such files)

Same questions here as the other PR, they're actually more relevant here.

What's the status of this PR

Ready to be merged

What are the limitations if any?

Other than 100mb file size limit - none

Is the PR title up to date?

Yes

It's ok if you merge this and possibly revisit the helper later. That part might require larger codebase changes.

Thanks for this! I look forward to using it in a tagged release!