Coverage uploads silently dropped on busy default branches due to "not the latest commit" rejection

Problem

On repositories with frequent merges to the default branch, coverage uploads for push events are almost always rejected with:

Warning: Coverage upload returned HTTP 200 (report not stored): Coverage report for <sha> cannot be uploaded for main because it is not the latest commit on the branch

This happens because CI takes time (install deps, build, test, upload) — often several minutes. In an active repository, another PR is typically merged to main before the workflow finishes. At that point the commit that triggered the workflow is no longer the branch tip, and the API refuses to store the report.

The result is that busy repositories can never get coverage data on their default branch, which is the primary use case for tracking coverage trends over time.

Reproduction

1. Have a repository with frequent merges to main (e.g. multiple per hour)
2. Configure the action on push to main
3. Observe that coverage uploads succeed only when no other commit lands on main during the CI run — which on active repos is rare

Suggested improvement

Looking at action.yml, for push events the action currently sends:

COMMIT_OID="${{ github.sha }}"
REF="${{ github.ref }}"

The server-side API then validates that COMMIT_OID is the current tip of REF and rejects otherwise. This design makes coverage upload inherently racy for any branch with concurrent activity.

Proposed solution

Coverage data is valid for the commit it was generated from, regardless of whether newer commits exist on the branch. The API should accept and store coverage for any commit reachable on the ref, not only the tip. The "latest" constraint could be relaxed to:

1. Accept coverage for any commit on the branch — Store it keyed by commit SHA. The UI/API can still display the most recent report when showing "current branch coverage," but historical reports for older commits remain queryable and useful (e.g. for trend lines, PR comparisons against the base commit at the time the PR was opened).

2. If the API must keep "latest only" semantics for display purposes, at minimum allow uploads for commits that were the tip when the workflow was triggered (i.e. trust the push event's SHA as valid), even if the tip has since advanced. The workflow event itself proves the commit was on the branch.

Alternative client-side mitigations (less ideal)

• Retry with updated SHA: The action could fetch the current branch tip and re-upload, but the coverage data wouldn't match that commit's code — this is semantically wrong.
• Upload earlier in the workflow: Not practical since coverage requires tests to complete first.

Impact

This affects any team using the action on a default branch with more than a handful of merges per day. As adoption grows, this will become more prevalent. Currently there is no workaround — the upload either wins the race or the data is lost.

This is also tricky for us, because only run certain tests if the relevant code has changed. Future commits may not even trigger the test run.

Thank you for building this action. The integration is clean and the DX is excellent. This is the one rough edge we've hit in practice.

Start with action.yml to confirm the push-event commit and ref values, then investigate the server-side API validation that rejects non-tip commits. Done means coverage for a commit reachable on the ref is accepted and stored without requiring it to remain the latest branch tip.