`contract build` can expose an empty wasm to concurrent builds
维护者通常 1 天内回复
@leighmcculloch 已经在做这个了。
开始于 2026年10月15日。
评估
这个 Issue 还没有评估数据。
描述
What version are you using?
28.1.0 (main at d95abbc).
What did you do?
Ran two stellar contract build (or contract deploy/upload auto-build) processes at the same time on the same cargo workspace.
Note that this also happens in the auto_build integration tests and causes builds to fail sometimes. e.g. deploy_workspace_with_package_auto_builds in this run.
What did you expect to see?
Both builds succeed, with each reader seeing either the previous complete wasm or the new complete wasm.
What did you see instead?
The second build fails with ❌ error: unexpected end-of-file (at offset 0x0) after cargo reports Finished. Perhaps writing each rewrite to a temp file in the same directory and renaming it over the target could avoid the empty window while still breaking the deps/ hard link, though there may be other options worth weighing.
Thoughts
After cargo releases its build lock, inject_meta and filter_spec in cmd/soroban-cli/src/commands/contract/build.rs each rewrite the output wasm in place with fs::remove_file followed by fs::write, and fs::write creates an empty file before writing the bytes, so another process reading the same path in that window sees zero bytes. The remove-then-write pattern came from #1896 to break the hard link cargo keeps to deps/ (#1694), and the only step that writes to a temp file and renames into place today is --optimize, while the --out-dir copy uses fs::copy, which is also not atomic.
The file would not exist as a zero length file for a brief period if it was written to a temp directory, or with a random filename in the current directory, then renamed into place after the write is complete. So this is probably the ideal fix.
- 主要语言
- Rust
- 星标
- 129
- 派生
- 153
- 平均合并
- 1 天 14 小时
- 30 天内合并 PR
- 11
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
stellar/stellar-cli 的其他 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 72/100
stellar/stellar-cli#2887 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
stellar/stellar-cli#2880 ·
维护者通常 1 天内回复
-
arg_value_union panics on zero-arity union tuple case (unchecked type_[0] index)可能已有人在做 @hvoi 于 22 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 72/100
stellar/stellar-cli#2806 · 1 条评论 ·
维护者通常 1 天内回复
-
contract extend panics on single-change resultMetaXdr (index out of bounds at extend.rs:306)可能重新可做 @duongynhi000005-oss 于 18 天前认领，目前没有进行中的 PR。 未关闭
难度 1/5 1 小时以内 新手友好度 90/100
stellar/stellar-cli#2796 · 1 条评论 ·
维护者通常 1 天内回复
-
Document stellar-cli's RPC trust boundary可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 1/5 1-3 小时 新手友好度 85/100
stellar/stellar-cli#2781 · 1 条评论 ·
维护者通常 1 天内回复
查看 stellar/stellar-cli 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
documentation
难度 2/5 1-3 小时 新手友好度 76/100
SO4-Markets/so4-oracle#1477 · 1 条评论 ·
维护者通常 1 天内回复