Trigger E2E Tests has failed on every push to main since 27 May #95

Problem

The trigger-e2e job in .github/workflows/ci.yml fails on every push to main:

##[error]Repository not found, OR token has insufficient permissions.
  repository: capiscio/capiscio-e2e-tests
  event-type: upstream-merge

It has failed on both pushes to main since the job was added:

Why it matters

Two effects, and the second is the expensive one.

Cross-product E2E has not run on merge for over three months. The job exists so E2E runs within minutes of a merge rather than waiting for the daily 6am cron. That path has been dead since the day it was introduced, so the only E2E signal has been the cron.

It makes main show red when the code is green. Both runs above passed Test, Lint, Security Scanning and Verify Protobuf, and both show as failures because of this one job. That is actively misleading: it cost real time during #94, where "CI red on main since 27 May" was inferred from the red X and turned out to be false — the code checks were green, only the dispatch was failing.

Cause

The job authenticates with secrets.REPO_ACCESS_TOKEN. A cross-repo repository_dispatch needs a token with write access to the target repository; the default GITHUB_TOKEN cannot do it, which is why a separate secret exists. GitHub returns the same "Repository not found, OR token has insufficient permissions" for all of: secret unset, token expired, token lacking repo scope, or token whose account cannot see capiscio/capiscio-e2e-tests.

The 404-instead-of-403 response is deliberate on GitHub's side and means the error cannot distinguish these, so this needs checking against the repository's actual secret configuration.

Fix

1. Confirm whether REPO_ACCESS_TOKEN is set on this repository, and whether it has expired.
2. If it needs reissuing, a fine-grained token scoped to capiscio/capiscio-e2e-tests with Contents: write is enough to dispatch, and is a smaller blast radius than a classic repo-scoped PAT.
3. Consider a GitHub App installation token instead, which does not expire on a calendar and can be scoped to the one repository.

Also worth deciding

Whether a dispatch failure should fail the CI run at all. It is a notification, not a verification: the code is fine either way. Options:

• continue-on-error: true on the step, so a dispatch outage does not turn main red
• keep it failing, but only if someone is actually watching that signal

Right now it fails loudly and nobody acted on it for three months, which is the worst of both.

Related

• fix(crypto): canonicalize agent cards per RFC 8785 #94 the E2E dispatch failure is why main reads red after that merge, despite all four code jobs passing