Fix GitHub webhook delivery + restore PR freshness in installed runtimes#690
Fix GitHub webhook delivery + restore PR freshness in installed runtimes#690arul28 wants to merge 2 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
Disabled knowledge base sources:
📝 WalkthroughWalkthroughThis PR adds a repo-access-pending detection mechanism to GitHubAppInstallPanel, including a retry delay schedule, request sequencing, polling logic after GitHub authorization, a new "Checking access" status view, UI button visibility adjustments, and accompanying unit tests. ChangesRepo Access Pending Detection and Retry Flow
Estimated code review effort: 3 (Moderate) | ~25 minutes Suggested labels: ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Wrong head branch (stale lane record) — superseded by the PR from ade/pr-state-sync-webhook-fallback. |
Summary
Describe the change.
What Changed
Key files and behaviors.
Validation
How you tested.
Risks
Anything to watch.
Summary by CodeRabbit
Greptile Summary
This PR adds a stale-update prevention layer and a post-authorization retry window to the GitHub App installation panel, so GitHub's App-access propagation delay is shown as a friendly "Checking access" state rather than a misleading "Check failed" error.
isGitHubAppRepoAccessPendingto detect GitHub 404/not-found error variants as transient access states, andstatusViewnow returns a "Checking access" label for that condition when the user is already authorized.loadStatusgains astatusRequestSeqRef+mountedRefguard that discards stale responses when a newer call supersedes them, and an optionalretryAfterAuthorizationpath that re-polls up to four times (1.5 s → 3 s → 6 s delays) while access is still propagating.Confidence Score: 4/5
The change is self-contained to a single UI component and introduces no new network surfaces or data mutations; the worst outcome of a bug here is a stale loading spinner or an incorrect status label, both recoverable by navigating away.
The sequence-number guard and mountedRef correctly discard stale async results in all observed scenarios, including React StrictMode double-invocation. The retry loop exits early as soon as access resolves, so the 10+ second wait only materialises when the repo truly isn't accessible yet. A minor timing window exists where the 'Waiting for repository access…' device message set inside the retry loop can briefly persist after a newer request takes over, but the succeeding request's finally block always corrects it. No state corruption or data loss paths were found.
The retry loop in GitHubAppInstallPanel.tsx (lines 47–59) is the densest part of the change and is worth a second read to confirm the stale-guard ordering matches expectations.
Important Files Changed
Flowchart
%%{init: {'theme': 'neutral'}}%% flowchart TD A[User completes device auth result.status === 'authorized'] --> B[setDeviceMessage 'Checking repository access...'] B --> C[loadStatus forceRefresh=true retryAfterAuthorization=true seq++, setLoading=true] C --> D[attempt 0: getAppInstallationStatus] D --> E{Stale? mountedRef or seq mismatch} E -- Yes --> Z[return early finally: skip setLoading] E -- No --> F[setStatus latestStatus] F --> G{isGitHubAppRepoAccessPending?} G -- No --> H[break loop] G -- Yes --> I[setDeviceMessage 'Waiting for repo access...'] I --> J[await sleepMs 1500 / 3000 / 6000 ms] J --> K{Stale?} K -- Yes --> Z K -- No --> L{More attempts?} L -- Yes --> D L -- No --> H H --> M[finally: isCurrentRequest?] M -- No --> Z M -- Yes --> N[await getAppUserAuthStatus] N --> O{Still current?} O -- No --> Z O -- Yes --> P[setAppAuth setDeviceMessage based on pending state setLoading=false] P --> Q{Access was pending after all retries?} Q -- Yes --> R[Show 'still warming up' message 'Checking access' status label] Q -- No --> S[Clear message Show resolved status]%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%% flowchart TD A[User completes device auth result.status === 'authorized'] --> B[setDeviceMessage 'Checking repository access...'] B --> C[loadStatus forceRefresh=true retryAfterAuthorization=true seq++, setLoading=true] C --> D[attempt 0: getAppInstallationStatus] D --> E{Stale? mountedRef or seq mismatch} E -- Yes --> Z[return early finally: skip setLoading] E -- No --> F[setStatus latestStatus] F --> G{isGitHubAppRepoAccessPending?} G -- No --> H[break loop] G -- Yes --> I[setDeviceMessage 'Waiting for repo access...'] I --> J[await sleepMs 1500 / 3000 / 6000 ms] J --> K{Stale?} K -- Yes --> Z K -- No --> L{More attempts?} L -- Yes --> D L -- No --> H H --> M[finally: isCurrentRequest?] M -- No --> Z M -- Yes --> N[await getAppUserAuthStatus] N --> O{Still current?} O -- No --> Z O -- Yes --> P[setAppAuth setDeviceMessage based on pending state setLoading=false] P --> Q{Access was pending after all retries?} Q -- Yes --> R[Show 'still warming up' message 'Checking access' status label] Q -- No --> S[Clear message Show resolved status]Reviews (1): Last reviewed commit: "Address GitHub App status review feedbac..." | Re-trigger Greptile