https://sonarly.com/issue/33071?type=bug
`checkCalendarAvailability` only catches `failedPrecondition` (HTTP 400) errors but Google also returns HTTP 403 with "The user must be signed up for Google Calendar." for accounts without Calendar provisioned. This unhandled 403 bubbles up as an uncaught error to Sentry and shows a confusing error redirect to the user.
Fix: Extended `isServiceNotEnabledError()` in `GoogleApisServiceAvailabilityService` to handle HTTP 403 errors where Google returns "The user must be signed up for Google Calendar." (or similar "must be signed up" messages for any Google service).
**What changed:**
1. **`google-apis-service-availability.service.ts`**: The `isServiceNotEnabledError` method now also checks for HTTP 403 responses with error messages containing "must be signed up". Previously it only handled HTTP 400 `failedPrecondition` errors. The fix:
- Extracts the HTTP status code from `error.response.status` (previously only `error.response.data.error` was used)
- After checking the existing `failedPrecondition` conditions, adds a second check: if the response status is 403 AND the error message contains "must be signed up", the error is classified as service-not-enabled
- Renamed `gmailError` → `googleError` since this method handles both Gmail and Calendar errors
2. **`google-apis-service-availability.service.spec.ts`**: Added a test case that simulates the exact error from the Sentry event — a 403 response with `reason: 'notACalendarUser'` and message "The user must be signed up for Google Calendar." — and verifies that `checkServicesAvailability` returns `isCalendarAvailable: false` instead of throwing.
**Why this approach:**
- Follows the same pattern as the previous fix (commit e7f958c9cf) which extended the error classifier
- The condition `isForbidden && isNotSignedUp` is specific enough to avoid false positives (requires both 403 status AND "must be signed up" in the message)
- The fix handles the error at the right layer — the availability check returns `false`, allowing the OAuth flow to continue with Gmail-only integration (or show a proper error if neither service is available)
**Monitoring impact:**
By catching this error in `isServiceNotEnabledError`, it no longer propagates as a raw GaxiosError to the controller's catch block, which means `GuardRedirectService.captureException()` is never called for this error. This eliminates the Sentry noise without any separate monitoring code changes.
Sonarly Claude Code
8822ffb305