Problem
The GitHub Grid Explorer can appear complete even when GitHub API data is incomplete because the viewer is rate-limited or a fetch partially fails.
For this kind of cockpit UI, incomplete data is risky: a user may browse the grids and make decisions as if all repositories/issues/PRs/workflows were present.
Desired behavior
When the app detects a rate limit or partial data failure:
- show a top-level banner such as GitHub data incomplete;
- mark affected grids/sections with warning badges;
- open a first-detection modal explaining that the current view may be missing data;
- include clear actions:
- Retry
- Continue with partial data
- later, optionally Use a token / sign in
The modal should not be generic error noise. It should protect the user from mistaking partial data for complete data.
Detection notes
Likely signals:
- GitHub API
403 / 429 responses;
X-RateLimit-Remaining: 0;
X-RateLimit-Reset for retry timing;
- any fetch group where some resources succeed and others fail.
Acceptance sketch
- Simulate rate-limited API responses in local/mock data.
- Verify the banner and modal appear.
- Verify affected grids are visually marked as incomplete.
- Verify the user can dismiss/continue, but the warning state remains visible.
- Verify successful retry clears the incomplete-data warning.
Problem
The GitHub Grid Explorer can appear complete even when GitHub API data is incomplete because the viewer is rate-limited or a fetch partially fails.
For this kind of cockpit UI, incomplete data is risky: a user may browse the grids and make decisions as if all repositories/issues/PRs/workflows were present.
Desired behavior
When the app detects a rate limit or partial data failure:
The modal should not be generic error noise. It should protect the user from mistaking partial data for complete data.
Detection notes
Likely signals:
403/429responses;X-RateLimit-Remaining: 0;X-RateLimit-Resetfor retry timing;Acceptance sketch