PR #129

Bug fix: merge status & CI check detection

These bugs exist on main and were not introduced by this PR. This commit fixes them.

1. Wrong API endpoint for CI checks

The code was using the commit status API (/commits/{sha}/status), but this repo's CI uses GitHub Actions, which create check runs — a separate system. The commit status endpoint returned state: "pending" with zero statuses for every PR, since nothing in this repo writes commit statuses. Switched to the check runs API (/commits/{sha}/check-runs), which returns the actual CI results.

2. mergeable: null treated as conflicts

GitHub computes mergeability lazily. The first API request after a change often returns mergeable: null (not yet computed). The code treated null as false, showing false "Merge conflicts" for PRs that are perfectly mergeable. Now defaults to true when null, and the next ISR revalidation cycle (5 min) picks up the real value.

3. Graceful degradation on API errors

Both getPRMergeStatus and getCommitStatus previously returned false on any API error (including rate limiting), which made every PR appear broken. Now defaults to true (optimistic) on errors — better to briefly miss a real conflict than to mark the entire page as broken.

So finally we get rid of that Rust Rewrite appearing on top which was appearing since week 1 ig

I'd also make them gray

Great idea; added!

I'd also make them gray

🤖 OpenChaos Bot

Summary: This PR modifies the sorting logic of open PRs to prioritize mergeable PRs and adds the getHeaders function. It also cleans up the headers object to be more robust.

Files changed: 1 (src/lib/github.ts)

Impact: Medium - Improves PR ranking by considering mergeability which affects visibility.

openchaos-bot

Summary

PRs with merge conflicts can't win the daily merge, but they currently appear at the top of the list if they have the most votes. This creates confusion when a high-voted PR doesn't win.

This PR makes the displayed ranking match the actual winner selection methodology. By moving conflict PRs to the bottom, users can follow along and understand why certain PRs were accepted and why others weren't.

Changes:

• PRs with merge conflicts are moved to the bottom of the ranking list
• Within each group (mergeable / has conflicts), PRs still sort by votes, then by newest

Attribution

This PR incorporates the auth header fix from #119 by @skridlevsky. The merge conflict indicator was showing false positives because getPRMergeStatus() and getCommitStatus() were missing auth headers.

Screenshots