Bug Description
auditRepos() uses Promise.allSettled() when fetching issue data, but never inspects the settled results. The per-repo fetch is assigned to map[...] inside the callback passed to allSettled, so when fetchIssues() rejects, that assignment simply never runs — the failure is silently discarded and the repo is dropped from issuesData with no record that it failed.
Separately, both runAudit() and runGovernanceAnalysis() set auditComplete via setAuditComplete(!!pat) — based only on whether a PAT is present, not on whether the fetches actually succeeded. As a result, a PAT being connected can cause the audit to be marked "complete" even when one or more repositories failed to load.
fetchWithCache() already throws real errors for 403, 404, and other non-ok responses, so this can happen from a genuine rate limit, missing repo, server error, or network failure — not just in a contrived test scenario.
Steps to Reproduce
- Connect a GitHub PAT.
- Run the Governance audit.
- Cause one
fetchIssues() request to fail (for example, due to a rate limit, inaccessible repository, server error, or temporary network failure).
- Re-run the audit.
Expected: Failed repositories are tracked/reported, and the audit is not represented as fully complete.
Actual: The affected repository shows "No data" and silently disappears from issuesData, while auditComplete is still set to true (since it's derived only from PAT presence), so the audit is reported as complete despite the partial failure.
Logs and Screenshots
Relevant code (src/context/AppContext.jsx):
const auditRepos = useCallback(async (allRepos) => {
const repos = selectAnalysisRepos(allRepos)
const map = {}
for (let i = 0; i < repos.length; i += 5) {
const batch = repos.slice(i, i + 5)
await Promise.allSettled(batch.map(async repo => {
map[${repo.orgLogin}/${repo.name}] = await fetchIssues(repo.orgLogin, repo.name, pat)
}))
}
return map
}, [pat, selectAnalysisRepos])
const runAudit = useCallback(async () => {
...
setAuditComplete(!!pat) // <-- not based on fetch outcomes
}, ...)
Same setAuditComplete(!!pat) pattern is duplicated in runGovernanceAnalysis().
fetchWithCache (src/services/github.js) confirms real errors propagate:
if (res.status === 403) throw new Error('RATE_LIMIT')
if (res.status === 404) throw new Error('NOT_FOUND')
if (!res.ok) throw new Error(HTTP_${res.status})
In a local reproduction, forcing fetchIssues() for PictoPy to fail caused its Governance result to change from 72% to No data, while the other repository results remained available.
Environment Details
Repo: AOSSIE-Org/OrgExplorer, main branch (current as of this report).
OS: macOS
Browser: Google Chrome
Affected files: src/context/AppContext.jsx (auditRepos, runAudit, runGovernanceAnalysis), src/services/github.js (fetchWithCache, fetchIssues).
The behaviour is reproducible with a GitHub PAT when one or more repository issue-data requests fail, such as due to a rate limit, inaccessible repository, server error, or temporary network failure.
Impact
Medium - Feature works but has issues
Code of Conduct
Bug Description
auditRepos()usesPromise.allSettled()when fetching issue data, but never inspects the settled results. The per-repo fetch is assigned tomap[...]inside the callback passed toallSettled, so whenfetchIssues()rejects, that assignment simply never runs — the failure is silently discarded and the repo is dropped fromissuesDatawith no record that it failed.Separately, both
runAudit()andrunGovernanceAnalysis()setauditCompleteviasetAuditComplete(!!pat)— based only on whether a PAT is present, not on whether the fetches actually succeeded. As a result, a PAT being connected can cause the audit to be marked "complete" even when one or more repositories failed to load.fetchWithCache()already throws real errors for403,404, and other non-ok responses, so this can happen from a genuine rate limit, missing repo, server error, or network failure — not just in a contrived test scenario.Steps to Reproduce
fetchIssues()request to fail (for example, due to a rate limit, inaccessible repository, server error, or temporary network failure).Expected: Failed repositories are tracked/reported, and the audit is not represented as fully complete.
Actual: The affected repository shows "No data" and silently disappears from
issuesData, whileauditCompleteis still set totrue(since it's derived only from PAT presence), so the audit is reported as complete despite the partial failure.Logs and Screenshots
Relevant code (src/context/AppContext.jsx):
const auditRepos = useCallback(async (allRepos) => {
const repos = selectAnalysisRepos(allRepos)
const map = {}
for (let i = 0; i < repos.length; i += 5) {
const batch = repos.slice(i, i + 5)
await Promise.allSettled(batch.map(async repo => {
map[
${repo.orgLogin}/${repo.name}] = await fetchIssues(repo.orgLogin, repo.name, pat)}))
}
return map
}, [pat, selectAnalysisRepos])
const runAudit = useCallback(async () => {
...
setAuditComplete(!!pat) // <-- not based on fetch outcomes
}, ...)
Same
setAuditComplete(!!pat)pattern is duplicated inrunGovernanceAnalysis().fetchWithCache (src/services/github.js) confirms real errors propagate:
if (res.status === 403) throw new Error('RATE_LIMIT')
if (res.status === 404) throw new Error('NOT_FOUND')
if (!res.ok) throw new Error(
HTTP_${res.status})In a local reproduction, forcing
fetchIssues()for PictoPy to fail caused its Governance result to change from72%toNo data, while the other repository results remained available.Environment Details
Repo: AOSSIE-Org/OrgExplorer, main branch (current as of this report).
OS: macOS
Browser: Google Chrome
Affected files: src/context/AppContext.jsx (auditRepos, runAudit, runGovernanceAnalysis), src/services/github.js (fetchWithCache, fetchIssues).
The behaviour is reproducible with a GitHub PAT when one or more repository issue-data requests fail, such as due to a rate limit, inaccessible repository, server error, or temporary network failure.
Impact
Medium - Feature works but has issues
Code of Conduct