OUT-3703: drop Sentry capture for QBReconnectRequiredError in cron#248
Conversation
…cron The cron has no Copilot user context, so it can't notify the IU on revocation — the captured event was unactionable noise on the team's side. Notification + disable-sync is already owned by the webhook auth path (AuthService.getQBPortalConnection) which has user context. The remaining gap — dormant portals that never get a webhook — is tracked as a follow-up. Catch-all branch still captures non-revocation errors as before. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryThis PR removes the
Confidence Score: 4/5Safe to merge — the change is a deliberate, well-reasoned reduction in Sentry noise with no functional impact on token refresh logic. The service change itself is correct and the existing generic-error Sentry path is untouched. The only gap is that the test comment documents 'no Sentry event for reconnect errors' but the assertion body doesn't enforce it, so the contract could regress silently. The test file would benefit from a negative Sentry assertion to lock in the documented behavior. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[refreshExpiringTokens cron] --> B[getPortalsWithExpiringRefreshTokens]
B --> C{For each portal row}
C --> D[getRefreshedQbTokenInfo]
D -->|success| E[summary.refreshed += 1]
D -->|QBReconnectRequiredError| F[summary.reconnectRequired += 1]
F --> G[CustomLogger.error — log only]
G -->|previously| H["~~Sentry.captureException~~ REMOVED"]
G --> I[continue to next portal]
D -->|other error| J[summary.errored += 1]
J --> K[CustomLogger.error]
K --> L[Sentry.captureException — still active]
E --> C
I --> C
L --> C
C -->|done| M[return RefreshTokensSummary]
|
No description provided.