go-cache-plugin: stale build object served after a source change (shared cache)
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 需要澄清
- 活跃度
- 活跃
- 技术栈
- aws, go
- 领域
- build-system, cloud
调研方向
未指定任何文件或测试。首先跟踪 plugin 的 actionID 键构造以及 Get 对 outputID 的处理，然后将这些假设与 cmd/go 针对共享 toolchain 和变体的 cache 行为进行比较；完成的条件是已就修复范围达成一致，并且有证据表明不再提供共享 cache 中的过期对象。
由索引模型根据 Issue 内容生成。
描述
Summary
Running many concurrent CI jobs against a single shared S3 cache prefix, a build occasionally compiles a package from stale source at a commit where that package's source has changed — the cache returns an object whose inputs no longer match. It surfaces as a coverage profile containing block ranges from two different revisions of the same file, and the affected job shows a ~99.9% cache-hit rate, so the stale bytes came from the cache, not a local rebuild. A manual purge of the prefix clears it; it recurs within a pipeline or two.
The failing job is only where it's detected. The same path would serve a stale object to a normal build silently, producing a binary from old source with no error — so we treat this as a correctness issue.
Questions after looking at code:
- The plugin keys purely on the actionID that
cmd/goprovides. For a cache shared across toolchains and build variants, should the key be salted with additional build context (toolchain version, cover mode, flags) — or is fully distinguishing builds consideredcmd/go's responsibility, and this is really acmd/goactionID-completeness issue rather than a plugin one? Getreturns the cached object without verifying its content against the requestedoutputID(the comment defers content-address checking to the toolchain). Would you accept a verify-on-GET (or read-only) mode that treats a hash mismatch as a miss and rebuilds, rather than returning stale bytes? For a shared multi-writer cache that would convert a silent stale-serve into a safe miss.
I can do the fix, if issue is accepted.
- 主要语言
- Go
- 星标
- 85
- 派生
- 22
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
tailscale/go-cache-plugin 的其他 Issue
-
put_s3_object and put_s3_found metrics are swapped可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 1/5 1 小时以内 新手友好度 90/100
tailscale/go-cache-plugin#25 ·
-
难度 5/5 一周以上 新手友好度 30/100
tailscale/go-cache-plugin#24 · 1 条评论 ·
-
Support a read-only mode可能已有人在做 @maboehm 于 227 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 45/100
tailscale/go-cache-plugin#19 ·
-
GCS support未关闭
难度 3/5 1-2 天 新手友好度 45/100
tailscale/go-cache-plugin#15 · 1 个 reaction ·
-
难度 4/5 3-5 天 新手友好度 35/100
tailscale/go-cache-plugin#13 · 3 条评论 · 2 个 reaction ·
查看 tailscale/go-cache-plugin 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 73/100
prime-radiant-inc/evener#5028 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 85/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
-
[BUG] v4.2.9 PostgreSQL 启动迁移失败：DROP INDEX CURRENT_SCHEMA() 语法错误可能已有人在做 @renovate 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
OpenListTeam/OpenList#3267 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 88/100
openpubkey/opkssh#670 ·
维护者通常 1 天内回复