Quality: Stack overflow risk in bytesToBase64 due to large spread operator

[tomaioo]

Summary

Quality: Stack overflow risk in bytesToBase64 due to large spread operator

Problem

Severity: High | File: packages/app-expo/src/lib/rag/auto-vectorize-book.ts:L33

The bytesToBase64 function spreads a Uint8Array chunk of size 0x8000 (32768) into String.fromCharCode(...). Most JavaScript engines have a maximum argument count limit (typically ~65536 but often lower in practice), and spreading such a large array will cause a 'Maximum call stack size exceeded' error for files larger than ~32KB.

Solution

Replace the spread operator with a loop or use a smaller chunk size (e.g., 0x1000 or 4096). Alternatively, use Array.from(chunk, b => String.fromCharCode(b)).join('') or a TextDecoder-based approach to avoid stack overflow.

Changes

• packages/app-expo/src/lib/rag/auto-vectorize-book.ts (modified)

[codedogQBY]

中文：这个修复方向是对的，但目前只改了 packages/app-expo/src/lib/rag/auto-vectorize-book.ts 里的 bytesToBase64。同样的 String.fromCharCode(...chunk) 还存在于 packages/app-expo/src/stores/library-store.ts 和 packages/app-expo/src/screens/LibraryScreen.tsx，这些移动端导入/回退提取路径仍然可能在大文件或大字节数组上触发 Maximum call stack size exceeded。建议把 base64 转换抽成一个安全 helper，或者至少同步修掉所有 call sites 后再合并。

English: The fix is in the right direction, but it only updates bytesToBase64 in packages/app-expo/src/lib/rag/auto-vectorize-book.ts. The same String.fromCharCode(...chunk) pattern still exists in packages/app-expo/src/stores/library-store.ts and packages/app-expo/src/screens/LibraryScreen.tsx, so mobile import/fallback extraction paths may still hit Maximum call stack size exceeded for large byte arrays. Please centralize this into a safe base64 helper or update all call sites before merge.