Summary

• Coverage uploads previously took the blob SHA of code-coverage.datadog.{yml,yaml} and CODEOWNERS from local HEAD (git rev-parse HEAD:<path>), while the commit SHA on the same payload comes from CI env vars (GIT_HEAD_SHA || GIT_SHA). Those two values aren't tied to each other — when they diverge, the splitter receives a (commit, path, blob_sha) triple where the file isn't actually in the reported commit's tree.
• This causes downstream ci-coverage-splitter to call source-code-query.GetCodeContent with that triple, get NotFound: resource not found, retry 10× (NotFound is treated as transient), then reject/stash the event. Coverage silently disappears for that build.
• Fix: resolve the blob SHA against the same commit that ends up on the wire (git rev-parse <reportedCommit>:<path>). The triple becomes internally consistent by construction; if the file isn't at that commit, getRepoFile returns undefined and the splitter falls back to its gitdb lookup as before.

Why local HEAD and the reported commit diverge in practice

• GitHub Actions PR builds check out the synthetic refs/pull/N/merge ref; HEAD's tree contains files brought in by merging with the base, but GITHUB_SHA (and therefore the reported commit) is the PR head. Files added on base only land in the merge tree, not at the PR head.
• DD_GIT_COMMIT_SHA / --git-commit-sha overrides the commit reported on the payload but not the blob computation.
• CI generates/commits the config locally before upload — local HEAD has it, but that commit isn't pushed and doesn't match the reported commit.
• Any detached-HEAD setup where env vars and the working tree don't agree.

Repro that motivated this

A real prod failure: ci-coverage-splitter rejected events for github.com/gojitsucom/mobile-warehouse-flutter with

*fmt.wrapError: failed to split coverage data for event:
  failed to get code content: rpc error: code = NotFound desc = resource not found

• Reported commit_sha: c0f9b4840cca576286661e5af25b666261e56919 — gitdb tree at that commit has 2,015 files, none named code-coverage.datadog.yml.
• Reported (path, blob_sha): code-coverage.datadog.yml, dbf70404459f7c35ee75ae1621e8a4af4c128af2.
• Sibling commit f71ded839e08d43c221fa827c39801320c343d1c does contain code-coverage.datadog.yml, and its blob SHA there is exactly dbf70404459f7c35ee75ae1621e8a4af4c128af2 — i.e. the upload was generated when local HEAD pointed at f71ded8… while CI declared c0f9b484… as the commit.

After this change, the blob sha is taken from c0f9b484…:code-coverage.datadog.yml, which doesn't exist → getRepoFile returns undefined → splitter falls back to gitdb (which won't find it either, but that path is handled gracefully and doesn't reject the event).

Test plan

• yarn build clean
• yarn lint clean
• yarn test packages/plugin-coverage packages/base/src/commands/git-metadata — all 160 tests pass
• Manual end-to-end on a CI provider where local HEAD differs from the reported commit (e.g., a GitHub Actions PR build) and confirm:
  • when the file exists at the reported commit, it is shipped and resolved correctly downstream;
  • when it doesn't, getRepoFile returns undefined (no event rejection downstream).

🤖 Generated with Claude Code