Bug Description
When GitHub API rate limits are hit during runAudit(), the error is swallowed by fetchIssues(), which catches all exceptions and returns an empty array.
As a result:
- runAudit() continues execution.
- Governance/Analytics pages display partial audit results.
- Users receive no indication that data is incomplete.
- The behavior differs from explore(), which correctly surfaces rate-limit errors.
Expected Behavior
If a GitHub rate-limit error (HTTP 403) occurs during an audit:
- The audit should stop or be marked as incomplete.
- The user should receive a clear notification/error message.
- Results should not appear as a successful complete audit when data is missing.
Actual Behavior
fetchIssues() returns [] for all errors, including rate-limit failures, causing the audit to proceed silently with incomplete data
Steps to Reproduce
Prerequisites: No PAT configured (unauthenticated = 60 req/hr limit)
Step 1 — Exhaust your rate limit
Open the app without a PAT set in Settings. Search for 2–3 large organizations. Each explore() call fetches org metadata + up to 500 repos + contributors for top 10 repos per org. This burns through the 60 req/hr unauthenticated limit quickly.
You can verify your limit is near exhaustion by checking the Rate Limit Banner (appears when remaining ≤ 20% of limit) or going to Settings and checking the quota display.
Step 2 — Navigate to Governance page
After the explore completes, go to Governance → Run Audit. runAudit() will begin fetching issues for the top 15 repos in batches of 5.
Step 3 — Observe the silent failure
While the audit is running (or after it finishes), if the rate limit hits mid-batch:
- The govLoading spinner disappears normally — as if the audit completed successfully
- The Governance page shows stat cards with counts (e.g., "Dead Issues: 0", "Zombie PRs: 0")
- The Analytics page shows "No trend data" or flat charts
- No error message is shown anywhere
- No banner or warning indicates that some repos returned no data
Logs and Screenshots
Environment Details
OS : Windows 11
Browser : Brave
Node.js: 22.18.0
Impact
Medium - Feature works but has issues
Code of Conduct
Bug Description
When GitHub API rate limits are hit during runAudit(), the error is swallowed by fetchIssues(), which catches all exceptions and returns an empty array.
As a result:
Expected Behavior
If a GitHub rate-limit error (HTTP 403) occurs during an audit:
Actual Behavior
fetchIssues() returns [] for all errors, including rate-limit failures, causing the audit to proceed silently with incomplete data
Steps to Reproduce
Prerequisites: No PAT configured (unauthenticated = 60 req/hr limit)
Step 1 — Exhaust your rate limit
Open the app without a PAT set in Settings. Search for 2–3 large organizations. Each explore() call fetches org metadata + up to 500 repos + contributors for top 10 repos per org. This burns through the 60 req/hr unauthenticated limit quickly.
You can verify your limit is near exhaustion by checking the Rate Limit Banner (appears when remaining ≤ 20% of limit) or going to Settings and checking the quota display.
Step 2 — Navigate to Governance page
After the explore completes, go to Governance → Run Audit. runAudit() will begin fetching issues for the top 15 repos in batches of 5.
Step 3 — Observe the silent failure
While the audit is running (or after it finishes), if the rate limit hits mid-batch:
Logs and Screenshots
Environment Details
OS : Windows 11
Browser : Brave
Node.js: 22.18.0
Impact
Medium - Feature works but has issues
Code of Conduct