Repository navigation
fix(integrations): accept the reported PR head ref in PR-link verification - #8384
Conversation
…ation The PR-link verifier required the PR head ref to equal both the session's stored branch and the branch the session reported pushing, so a session that pushed its PR from another branch could never verify its own link. Use the reported head ref as the branch evidence and the session's stored branch only as the fallback for a link that carries none, and apply the same rule in the webhook verification SQL so both paths agree.
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Executive SummaryThe only change since the previous review is a doc-comment update in Files Reviewed (6 files cumulative, 1 in incremental diff)
Tests were not executed in this read-only review; assessment is based on static analysis of the incremental diff and the current verifier/webhook call sites. Previous Review Summary (commit 20c776a)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit 20c776a)Status: No Issues Found | Recommendation: Merge Executive SummaryThe verifier and the webhook SQL gate now apply the same head-ref rule ( Files Reviewed (5 files)
Tests were not executed in this read-only review; the assessment is based on static analysis of the diff, the current router/webhook call sites, and the ingest normalization of Reviewed by deepseek-v4.1-flash-1017 · Input: 33.7K · Output: 3K · Cached: 271K Review guidance: REVIEW.md from base branch |
…tion The refresh mutation's doc comment still said the PR head ref must be the session's branch. It is the branch the session reported pushing, with the stored branch only for a link that carries none.
What changed
PR-link verification required the PR head ref to equal both the session's stored
git_branchand the branch the session reported pushing (pr_head_ref). When those differ — a session that pushes its PR from another branch than the one it recorded — no PR head ref could satisfy both, so the session's own link was always rejected.apps/web/src/lib/integrations/platforms/github/pr-link-identity.ts:verifySessionPullRequestLinkusespr_head_refas the PR-head-ref evidence and falls back to the storedgit_branchonly for a link that carries no head ref. The session repo, PR URL repo, PR number, base repo, head repo and head-SHA/commit evidence rules are unchanged.apps/web/src/lib/integrations/platforms/github/webhook-handlers/upsert-cli-session-pull-requests.ts: the webhook gate applies the same rule in SQL —coalesce(nullif(pr_head_ref, ''), nullif(git_branch, ''))must name the payload head ref. A stored head ref naming another branch still blocks the match; a differing stored branch no longer blocks a matching reported head ref. The head-SHA evidence predicate is unchanged.cli-sessions-v2-router.test.ts.End-to-end evidence
Local PostgreSQL (
pnpm test:db, migrations applied) on the work VM,NODE_ENV=test jestinapps/web.Branch (after):
Before the fix, with the two source files reverted and the new tests in place:
So the refresh procedure previously returned
associatedPr: nulland leftpr_link_verified_atunset for a session whose stored branch differs from the branch it reported pushing; with the change it returns the PR, writes thegithub_branch_pull_requestsrow and setspr_link_verified_at. The webhook path now verifies the same sessions.Checks:
oxlint0 warnings/0 errors on the changed files,oxfmt --list-differentclean,tsgo --noEmitexit 0 inapps/web.No visual surface: the change is a pure predicate plus SQL gate, verified through the real database-backed refresh procedure and the webhook handler.
Proxy answers
The owner's proxy gave these answers in the owner's place.
Answer: Also widen the webhook predicate
Confidence: 0.55 · Precedent: Fix the root cause and the class of the issue on every affected surface: session 75f8833fe8c1, "fix this for all shared services model pickers on all surfaces"; session 89824a222897, "if you saw a gap, fix it"