Route step computes ISSUE_IS_PR=false for fork pull_request_target events, silently blocking all agent dispatch

[fullsend-ai-retro]

What happened

PR #6590 was opened 2026-08-25 from fork guyoron1/fullsend. Three workflow runs fired over 12 days:

1. Run 32844079832 (Aug 25, opened): Route step logged ISSUE_IS_PR: false, concluded "No stage matched — skipping dispatch."
2. Run 33504286930 (Sep 1, ready_for_review): Same ISSUE_IS_PR: false, same skip.
3. Run 33504592708 (Sep 1, Qodo review submitted): Same ISSUE_IS_PR: false, plus harness dispatch hit a permission lookup failure for qodo-code-review[bot].

No fullsend review agent was ever dispatched. The only review came from Qodo, which found 3 high-severity correctness bugs. The PR modified .github/workflows/reusable-dispatch.yml and .github/workflows/reusable-review.yml — the dispatch infrastructure itself — with zero fullsend review coverage.

What could go better

The ISSUE_IS_PR variable is computed as false for pull_request_target events from forks. Since the Route step's stage-matching branches for pull_request_target check ISSUE_IS_PR, the event never matches any stage and dispatch is silently skipped.

This is an upstream blocker that operates before the authorization check (is_event_actor_authorized). Existing issues #2967 and #4374 propose authorization-based solutions (org membership, ok-to-test label) for fork PR dispatch. However, if ISSUE_IS_PR remains false for forks, those authorization checks may never be reached — the route step exits at stage-matching before evaluating actor authorization.

Issue #6796 describes a 14-day dispatch delay on a fork PR in another repo with "unclear root cause." The ISSUE_IS_PR: false computation is likely the same mechanism.

Confidence: High that ISSUE_IS_PR: false is the proximate cause of the dispatch skip — three runs on the same PR all show the same variable value and the same skip outcome. Moderate confidence that this blocks #2967/#4374, since I have not read the route script source to verify the exact control flow — the authorization check might be in a separate branch that does not depend on ISSUE_IS_PR.

Proposed change

Investigate the ISSUE_IS_PR computation in the Route step of .github/workflows/fullsend.yaml (or the reusable workflow that defines the route job). For pull_request_target events, the event is always a PR by definition — ISSUE_IS_PR should be true regardless of whether the PR comes from a fork. The likely fix is either:

1. Set ISSUE_IS_PR=true unconditionally when GITHUB_EVENT_NAME is pull_request_target or pull_request_review, or
2. Fix the API lookup that derives ISSUE_IS_PR to correctly resolve fork PR numbers against the base repo.

This fix is a prerequisite for any trust-gated fork PR dispatch (#2967, #4374). Without it, the authorization layer is never reached. The fix itself does not need to enable unrestricted fork PR dispatch — it just needs to let the route step proceed to the authorization checks that decide whether dispatch is safe.

Validation criteria

After the fix, pull_request_target events from fork PRs should show ISSUE_IS_PR: true in the Route step logs. The route step should proceed to stage-matching and authorization checks (which may still correctly block dispatch pending implementation of #2967 or #4374). Verify on the next 3 fork PRs to fullsend-ai/fullsend or any enrolled repo that previously showed the ISSUE_IS_PR: false / "No stage matched" pattern.

---

Generated by retro agent from #6590

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 8:27 AM UTC · Completed 8:34 AM UTC

Commit: 42b3b71 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $1.21

[fullsend-ai-triage]

Root cause correction: The ISSUE_IS_PR computation is indeed wrong for pull_request_target events, but it is not the cause of the dispatch skip observed on PR #6590. The pull_request_target routing path (lines 283–301 of reusable-dispatch.yml) does not check ISSUE_IS_PR — it routes directly via EVENT_ACTION and is_event_actor_authorized. The three workflow runs skipped dispatch because the fork PR author lacks triage permission on the base repo (runs 1–2) and because Qodo is not the expected review bot (run 3). This is the authorization behavior by design, tracked in #2967 and #4374.

What this issue actually fixes: A latent correctness bug where ISSUE_IS_PR evaluates github.event.issue.pull_request — which is null for pull_request_target events (the PR object is at github.event.pull_request). Fixing this has no current runtime impact since no pull_request_target code path reads ISSUE_IS_PR, but it prevents confusion if future refactors reference the variable.

Recommended fix:

ISSUE_IS_PR: ${{ (github.event_name == 'pull_request_target' || github.event_name == 'pull_request_review' || github.event.issue.pull_request) && 'true' || 'false' }}

⚠ This fix requires modifying workflow files (.github/workflows/reusable-dispatch.yml) — the code agent cannot modify workflow files under current permissions. Manual intervention is needed.

Related issues: #2967 and #4374 track the actual fork PR dispatch enablement. #6796 likely has the same root cause (authorization, not ISSUE_IS_PR).

---

Labels: Dispatch routing bug in workflow files affecting fork PR variable computation, low priority since no runtime impact.

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance