fix(knowledge): unschedule connectors only for credential revocations, not app configuration faults

[waleedlatif1]

Summary

• fix(knowledge): unschedule a connector whose credential the source rejected and prompt to reconnect #8158 unscheduled a connector whenever its credential's refresh dead flag was set, including for app-registration codes (invalid_client, bad_client_secret, invalid_client_id, bad_redirect_uri). Those are our config faults, not the owner's: one mis-rotated client secret would unschedule every connector of that provider until each owner reconnected, even after the fix
• Split the terminal code list in terminal-errors.ts into credential revocations and app-configuration faults, and export isCredentialRevocationError(code, providerId). isTerminalRefreshError is now the union of the two, so what gets dead-flagged is unchanged
• getCredentialTerminalRefreshError now returns { errorCode, providerId }. The sync engine uses the new predicate at both checks (token resolution and the pre-unschedule re-read), so only a revocation takes the unschedule-and-reconnect path. App-configuration faults go back to the ordinary failure ladder, which is how it worked before fix(knowledge): unschedule a connector whose credential the source rejected and prompt to reconnect #8158
• unauthorized_client still counts as a revocation only for Confluence and Jira. For other providers it is not terminal
• The dead flag is unchanged. For a config fault it still skips refresh attempts for its 1 h TTL, which is harmless: the connector's ladder backs off 30 min per failure, and once the flag expires after the config fix the next retry recovers. The flag does not need to be cleared when the config changes
• The UI reconnect prompt checks for CREDENTIAL_REVOKED_SYNC_ERROR, so it follows this change with no UI edit

Type of Change

• Bug fix

Testing

• Unit tests: isCredentialRevocationError classification. In the sync engine, invalid_client/bad_client_secret go to the ordinary ladder, invalid_grant unschedules, and unauthorized_client unschedules for Confluence but goes to the ladder for other providers
• Mutation-checked each guard: removing the predicate from the sync engine, dropping the providerId, counting app-config codes as revocations, dropping the provider map, and dropping providerId from the flag reader each turn the matching tests red
• lib/oauth, lib/knowledge/connectors, lib/credentials, lib/auth/connectors suites pass; lint, check:audits, type-check pass

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Skipped		Sep 23, 2026 12:01am UTC

[cubic-dev-ai]

No issues found across 7 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge, with the revised classification consistently applied and the previous repository-rule violation fully fixed.

Summary

This PR separates credential revocations from OAuth app-configuration faults while preserving the existing terminal refresh-error classification.

• Unschedules connectors only when the credential grant was revoked.
• Keeps connectors on the ordinary retry ladder for app-registration failures.
• Preserves provider-specific handling of unauthorized_client for Confluence and Jira.
• Returns the provider alongside terminal refresh errors so callers can classify provider-specific codes.
• Adds coverage for revocation, configuration-fault, and provider-specific paths.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[OAuth token resolution returns no token] --> B[Read terminal refresh error and provider]
  B --> C{Credential revocation?}
  C -->|Yes| D[Re-read revocation before recording outcome]
  D --> E{Still revoked?}
  E -->|Yes| F[Unschedule connector and request reconnection]
  E -->|No| G[Keep ordinary failure handling]
  C -->|No: configuration fault or no terminal error| G
  G --> H[Advance retry failure ladder]

Loading

_{Reviews (2) · Last reviewed commit: "test(knowledge): mark the revocation fix..."}

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 7 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}