Files
multica/server/internal/handler/github.go
Jiayuan Zhang 41586f1499 fix(github): surface in-flight CI on PR cards (MUL-2392) (#2887)
* fix(github): surface in-flight CI on PRs and recover out-of-order check_suite events

Two bugs caused PR cards to render "checks not reported yet" while CI
was actually running (MUL-2392):

1. handleCheckSuiteEvent dropped every action except `completed`, so
   `requested`/`rerequested` events (status queued/in_progress) never
   landed in the suite table. Aggregated `checks_pending` stayed at 0
   until the first suite finished, and the frontend fell through to the
   unknown bucket. Persist all actions; the ListPullRequestsByIssue
   aggregation already counts status<>completed as pending.

2. A check_suite for an unmirrored PR was logged and dropped, with no
   replay path. Add a `github_pending_check_suite` stash keyed by
   (workspace, repo, pr_number, suite_id); the pull_request webhook
   drains it after the PR upsert and replays each entry through the
   normal check_suite upsert. One-shot drain via DELETE … RETURNING
   keeps it idempotent and free of retry storms.

Follow-ups for fork PRs (empty `pull_requests[]`) and a more specific
frontend placeholder ship in separate issues.

Co-authored-by: multica-agent <github@multica.ai>

* fix(github): guard pending check_suite stash against out-of-order events

UpsertPendingCheckSuite previously overwrote unconditionally on
conflict, so an older `requested/in_progress` event arriving after a
newer `completed/success` for the same suite would roll the stash
back to pending. The subsequent PR upsert then drained the stale
state and the PR card stuck on "pending" until the next suite. Mirror
the suite_updated_at guard from UpsertPullRequestCheckSuite and add a
regression test covering the PR-missing path.

Co-authored-by: multica-agent <github@multica.ai>

---------

Co-authored-by: Lambda <lambda@multica.ai>
Co-authored-by: multica-agent <github@multica.ai>
2026-06-17 09:24:15 +02:00

52 KiB