E2E tests cancelled when another PR triggers a concurrent run

[rh-hemartin]

What happens: E2E tests on a PR get cancelled mid-run when another PR triggers a new workflow run, likely due to concurrency group settings. Example: PR #862 had its e2e job cancelled after 15 minutes.

https://github.com/fullsend-ai/fullsend/actions/runs/25792059935/job/75759863820

What should happen: E2E tests should run to completion before being replaced. They exercise the full install/uninstall flow against a live GitHub org and take significant time — cancelling them wastes that work and leaves the PR without a valid e2e result.

[github-actions]

fullsend triage is working on this — view logs

[fullsend-ai-triage]

Triage Summary

Severity: Medium · Category: Bug

Problem

The e2e.yml workflow uses a static global concurrency group (e2e-halfsend) with cancel-in-progress: false. GitHub Actions only allows one in-progress + one pending run per concurrency group. When a third run arrives, it cancels the previously-pending run — not the in-progress one.

Recent run history confirms the pattern: the referenced cancelled run and at least one other recent cancellation are visible in the workflow history.

Root Cause

The static concurrency group is likely intentional — e2e tests exercise install/uninstall flows against a shared live GitHub org, so parallel execution could cause conflicts. However, the current design doesn't gracefully handle more than two concurrent triggers, which is common during bursts of agent-generated PRs.

Recommended Fix

Three possible approaches, depending on whether parallel e2e execution is safe:

1. Per-PR concurrency group (e2e-${{ github.event.pull_request.number || github.ref }}): Only viable if tests use unique resources per run and won't conflict when running in parallel against the shared org.
2. Keep static group + add retry: A separate workflow or step that re-triggers cancelled e2e runs, ensuring every PR eventually gets results.
3. Queue management: Use a matrix strategy or external queue to serialize runs without relying on GitHub's limited 1-pending-run behavior.

Proposed Test

Scenario: Three PRs trigger e2e tests in quick succession
  Given three PRs that each modify Go source files
  When all three are pushed within a short window
  Then all three PRs should eventually have a completed
       (not cancelled) e2e workflow run
  And if runs execute concurrently, they should not
       interfere with each other's install/uninstall assertions

[github-actions]

fullsend code is working on this — view logs