perf(sidecar): raw-binary readFileSync transfer (skip base64)
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 52/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- javascript, rust
调研方向
从 crates/execution/src/v8_runtime.rs:183、crates/execution/assets/v8-bridge.source.js 和 crates/v8-runtime/src/host_call.rs 开始，跟踪现有的二进制响应路径。检查其他 {__agentOsType:"bytes"} 消费者，然后为二进制同步读取和 promise 读取添加覆盖，并确保 writeFileBinary 对称；完成标准是二进制读取使用 raw-binary 路径且不经过 base64。
由索引模型根据 Issue 内容生成。
描述
Background
Guest binary fs.readFileSync(path) (no encoding) goes
_fs.readFileBinary → _fsReadFileBinary → mapped to fs.readFileSync with the
binary flag (crates/execution/src/v8_runtime.rs:183) → host returns the bytes as
a base64-encoded JSON object (javascript_sync_rpc_bytes_value:
{ "__agentOsType": "bytes", "base64": "..." }), and the guest decodes with
Buffer.from(base64, "base64") (crates/execution/assets/v8-bridge.source.js).
So every binary file read pays base64 encode (host) + decode (guest) plus ~33%
payload inflation. The base64 round-trip is wasted work.
Proposal
Transfer file bytes as raw binary instead of base64. The bridge response
protocol already has a raw-binary path (status = 2 / Uint8Array, see
crates/v8-runtime/src/host_call.rs). Route readFileSync's binary result through
that path and have the guest do Buffer.from(uint8array) directly.
Why it wasn't done in PR #77
The sync-RPC return type is a serde_json::Value, which can't carry raw bytes —
hence the base64 representation. Switching readFileSync to the status=2
raw-binary response is a cross-cutting protocol change that affects every
binary file read, so it was deferred rather than rushed (read was already 6.2×
faster from the pump fix in #77). Needs careful implementation + tests for:
binary readFile (sync + promises), writeFileBinary symmetry, and the
{__agentOsType:"bytes"} consumers elsewhere.
Expected impact
Removes base64 encode/decode + ~33% payload inflation per binary read; helps
read-heavy guests (bundlers, asset pipelines, large node_modules).
- 主要语言
- TypeScript
- 星标
- 1k
- 派生
- 53
- 平均合并
- 2 小时 54 分钟
- 30 天内合并 PR
- 5
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
rivet-dev/dynamic-apps 的其他 Issue
-
Build cache ignores maxResponseBytes, potentially reusing an outdated response limit可能已有人在做 @Utkarshpandey0001 于 41 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 78/100
rivet-dev/dynamic-apps#297 ·
-
难度 3/5 1-2 天 新手友好度 58/100
rivet-dev/dynamic-apps#280 · 2 条评论 ·
-
Make agentOS runtime classifier content-based (match Linux exec semantics), not extension-based可能已有人在做 @mittal-parth 于 46 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 48/100
rivet-dev/dynamic-apps#275 ·
-
难度 4/5 3-5 天 新手友好度 55/100
rivet-dev/dynamic-apps#272 ·
-
Treat the WASM/WASI build target as cfg(unix) so filesystem tools need no per-tool mode-bit patches未关闭
难度 5/5 一周以上 新手友好度 35/100
rivet-dev/dynamic-apps#271 ·
查看 rivet-dev/dynamic-apps 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
components-web-app/docs#307 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
localstack/localstack-mcp-server#112 ·
维护者通常 1 天内回复
-
area:frontend kind:bug priority:p1 ready
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 1 天内回复
-
bug ready-for-agent
难度 2/5 1-3 小时 新手友好度 73/100
PhyberApex/kuroshiro#1687 ·
维护者通常 1 天内回复
-
Performance (Web Vitals) collector: LCP/FCP from background tabs are not discarded, inflating p75未关闭
难度 2/5 1-3 小时 新手友好度 74/100
umami-software/umami#4720 ·
维护者通常 3 天内回复