go-cache-plugin: stale build object served after a source change (shared cache)
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- バグ
- 明瞭さ
- 説明が足りない
- 活発さ
- 活発
- 技術スタック
- aws, go
- 領域
- build-system, cloud
調査の方向性
ファイルもテストも名前が挙げられていません。まず、plugin の actionID キーの構築と、Get による outputID の処理を追跡し、次にそれらの前提を、共有された toolchain と variant に対する cmd/go の 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 にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
tailscale/go-cache-plugin のほかの issue
-
put_s3_object and put_s3_found metrics are swapped再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
tailscale/go-cache-plugin#25 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
tailscale/go-cache-plugin#24 · コメント 1 件 ·
-
Support a read-only mode対応中かも @maboehm が 221 日前に担当しました。 オープン
難易度 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 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
tailscale/go-cache-plugin#13 · コメント 3 件 · リアクション 2 件 ·
tailscale/go-cache-plugin の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
apache/rocketmq-dashboard#7243 ·
メンテナーはふだん 3 日以内に返信
-
Missing example coverage: getClock対応中かも @camunda-sdk-automation が今日担当しました。 オープンnew-operations
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
camunda/orchestration-cluster-api-go#75 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
[schema-coverage] elasticstack_kibana_security_entity_store_status対応中かも @github-actions が今日担当しました。 オープンacceptance-tests phase-coding schema-coverage testing triaged
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
elastic/terraform-provider-elasticstack#5396 ·
メンテナーはふだん 1 日以内に返信
-
Go device SDK: Whisper transcriber keeps buffering and transcribing audio appended after Stop()対応中かも @apoorvdarshan が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
BasedHardware/omi#22770 ·
メンテナーはふだん 1 日以内に返信
-
Bug v3
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信