fix(core): restore Integration status to ENABLED on successful re-auth

[d-klotz]

Summary

When a user re-authorizes an integration whose parent Integration record is in a broken state (ERROR or DISABLED), the framework refreshes the credential correctly but leaves Integration.status untouched. The queue worker short-circuits on DISABLED (backend-utils.js:157,173), so webhooks are silently discarded forever even after the customer completes a new OAuth flow.

This PR walks from the re-authorized entity up to any parent integrations and flips those in {ERROR, DISABLED} back to ENABLED, so customer-driven reconnect actually recovers the integration.

This is Gap C of 3 from an RCA on Attio dead-token loops. Gap A (OAuth2Requester.refreshAuth unconditionally POSTs grant_type=refresh_token even when the stored refresh_token is null) and Gap B (no auto-flip to ERROR on DLGT_INVALID_AUTH) are separate upcoming PRs.

Changes

• New interface method findIntegrationsByEntityId(entityId) on IntegrationRepositoryInterface.
• Implementations:
  • Postgres: many-to-many via entities.some.id
  • Mongo: scalar-array via entityIds.has
  • DocumentDB: raw findMany with { entityIds: objectId }
• Use case ProcessAuthorizationCallback:
  • Accepts optional integrationRepository (backward compatible — omitted injection is a silent no-op).
  • At the end of execute(), calls new restoreIntegrationsForEntity(entityId) helper which looks up integrations referencing the entity and flips any in STATUSES_RESET_ON_REAUTH = ['ERROR', 'DISABLED'] to ENABLED.
  • Wrapped in try/catch so a DB hiccup never fails an otherwise-successful re-auth; logs console.error on failure.
  • Logs [Frigg] Restoring integration X from Y to ENABLED after successful re-auth (entityId=Z) for operator visibility.
• Wiring: integration-router.js passes the already-created integrationRepository to the ProcessAuthorizationCallback constructor.
• Test double TestIntegrationRepository extended with matching in-memory findIntegrationsByEntityId.

Semantic decision

Both ERROR and DISABLED are reset on re-auth. Reasoning: the user clicking "Reconnect" is an implicit opt-in to re-enable — whether the integration went bad via a system error or a manual user pause, the action of re-authorizing expresses intent to use it again. PROCESSING (active-run state) and NEEDS_CONFIG (config-incomplete, auth alone doesn't fix) are intentionally excluded.

Test plan

Unit tests (all 5 pass):

• ERROR integration flips to ENABLED
• DISABLED integration flips to ENABLED
• ENABLED integration is a no-op (no unnecessary updates)
• Empty integrations list (first-time auth) does not throw
• Mixed statuses: only broken ones flip, count is exact

Manual end-to-end verification on a local install:

• Integration id=48 set to status=DISABLED + Credential.authIsValid=false
• Completed full Attio OAuth re-auth flow
• Confirmed via GET /api/integrations and direct DB query:
  • Integration[48].status → ENABLED ✓
  • Credential[48].authIsValid → true
  • access_token advanced
  • Log line [Frigg] Restoring integration 48 from DISABLED to ENABLED after successful re-auth (entityId=60) present

🤖 Generated with Claude Code

[d-klotz]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[sonarqubecloud]

Quality Gate failed

Failed conditions
D Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE