tend-mention/handle: POST-job cleanup of local <setup> action fails on stale PR branches (followup to #391)

[prql-bot]

Problem

tend-mention's handle job fails during POST-job cleanup when fired by an issue_comment on a stale PR whose head branch predates the local ./.github/actions/<setup> composite action. The Claude session itself completes successfully and uploads its artifact — the failure happens after, when GitHub Actions tries to run the POST steps of nested actions inside <setup> and re-reads the composite's action.yaml from the workspace, which by then has been switched to the stale PR branch by gh pr checkout.

#391 fixed the forward step ordering by moving uses: ./.github/actions/<setup> ahead of gh pr checkout. The current generated tend-mention.yaml (0.0.24) is:

- uses: actions/checkout@v6
  with: { fetch-depth: 0, fetch-tags: true, token: ... }
- uses: ./.github/actions/tend-setup      # ✅ resolves against main
- name: Check out PR branch
  run: gh pr checkout "$PR_NUMBER"        # switches workspace to PR tree
- uses: max-sixty/tend@0.0.24

This works at run time. But at job end, the runner walks the POST chain in reverse. The POST handler for ./.github/actions/tend-setup re-opens the composite from the workspace path (<workspace>/.github/actions/tend-setup/action.yaml) — and if the PR branch lacks that path, it errors:

##[error]Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '/home/runner/work/<repo>/<repo>/.github/actions/tend-setup'. Did you forget to run actions/checkout before running your local action?

The error fires because nested actions inside the composite — at minimum Swatinem/rust-cache@v2 — have real POST steps the runner needs to dispatch.

Evidence

PRQL/prql, run 25987714522 (2026-05-17):

• Triggered by issue_comment on #5374 (Dependabot notify 7.0.0 → 8.2.0, opened 2025-09-12 — well before tend was added to PRQL on 2026-04-30 in #5727).
• gh pr checkout 5374 switched workspace to dependabot/cargo/notify-8.2.0. That branch has no .github/actions/tend-setup — confirmed via gh api repos/PRQL/prql/contents/.github/actions/tend-setup?ref=dependabot/cargo/notify-8.2.0 → 404.
• The Claude session exited silently (self-loop guard, correct behaviour) and uploaded claude-session-logs-6b8f824a.zip (36 KB).
• Then POST cleanup fired the error above. The job's conclusion is failure despite the session being correct.

Sibling run 25987714377 at the same minute, for #5543 (dependabot/cargo/ariadne-0.6.0 — a branch that does contain .github/actions/tend-setup), succeeded cleanly. Same workflow, same code paths — the only difference is whether the PR's head tree carries the action directory.

Why this matters

• Every consumer with a <setup> composite under .github/actions/ will hit this on any sufficiently old PR (long-lived feature branches, dependabot PRs that pre-date tend adoption, fork PRs not rebased).
• Failure is silent in the sense that the agent did its job correctly, but the run shows red on the PR's status rollup and looks indistinguishable from a real failure to a maintainer reading their CI dashboard.
• For PRQL specifically, the bot now needs maintainer attention on a comment thread where it actually did the right thing.

Possible fixes

Listing options without picking a winner — each has tradeoffs the maintainer is better placed to judge:

1. Restore default-branch checkout after the session. Add a post: step (or always() step before tend's own post chain) that does a git checkout origin/<default> of just the .github/actions/<setup>/ path, so the cleanup walker can find the action file. Smallest blast radius.
2. Copy the action dir to a stable location. Before gh pr checkout, copy .github/actions/<setup>/ to e.g. $RUNNER_TEMP/tend-setup/ and rewrite the workflow's uses: to that path. Defeats the issue but rewrites the action's resolution path.
3. Ship <setup> as a remote action, not a local composite. Resolves identically across all consumers; biggest change to the install-tend flow.

Same fix applies symmetrically to tend-review if/when it grows a gh pr checkout after the setup step (referenced as out-of-scope in #396).

Related

• fix(mention): run setup before PR checkout so stale PRs don't drop mentions #391 — fixed the forward step ordering for tend-mention (this issue is the POST-cleanup follow-up).
• tend-mention/handle: claude-setup local action step fails on PRs predating its addition #396 — closed when fix(mention): run setup before PR checkout so stale PRs don't drop mentions #391 merged; the closing thread flagged tend-review as remaining but didn't cover the POST-cleanup path.

[tend-agent]

Thanks — this is a clear writeup of a genuine follow-up to #391. The forward-step reorder put the local composite resolution onto the default branch's tree, but gh pr checkout still leaves the workspace on the PR's tree for POST cleanup. Any composite that nests actions with real POST steps (e.g. Swatinem/rust-cache) will hit this on PRs whose head predates the composite.

I haven't opened a fix — the three options presented each rewrite a different layer (post-restore vs. relocated copy vs. remote action), and I don't think there's a clear winner without maintainer input on which contract to preserve. Leaving for a maintainer to pick the shape; I'd note that the same patch would also want to cover tend-review if/when it grows the same two-step pattern flagged in #396's close-out.

A maintainer will take a look.

[max-sixty]

this will no longer be an issue after old PRs decay out, and everything is using a newer version; is that right?

[tend-agent]

Largely yes. The trigger is "PR head branch lacks .github/actions/<setup>/", and any PR branched from main after tend was installed will have the directory in its tree, so new PRs don't hit it. The remaining failure surface is branches that pre-date tend adoption and haven't been rebased since — chiefly the pre-existing dependabot PRs that only rebase on conflict (the PRQL case here is exactly that, #5374 opened 2025-08, tend added 2026-04). Those self-clear as they merge, close, or hit a conflict that forces a rebase.

So: a one-time hump per consumer at install time, self-limiting. No fix worth the complexity unless we see it on PRs that branched after tend adoption (e.g. very long-lived feature branches), which I'd treat as a separate report. Happy to close this on that basis if you'd like.