[Bug]: Add Error Handling for OAuth Provider Failures in Frontend

[Suvam-paul145]

Summary:

• Wrap OAuth provider calls in try/catch and return a structured error when the provider is unreachable.
• Show a user-friendly message in the UI when sign in fails due to provider unavailability.
• Add unit tests for the failure path and an e2e test for UI behavior.

Files changed:

• frontend/src/lib/server/auth.ts
• frontend/src/components/SignInButton.tsx (or equivalent)
• tests/unit/auth.spec.ts
• tests/e2e/auth-provider-failure.spec.ts

Why:

• Prevents frontend crashes/hangs when third-party auth services are down.
• Improves UX and observability.

How tested:

• Unit tests added for provider failure and 5xx responses.
• Playwright e2e simulating provider downtime and asserting the error toast.

Notes:

• Logging added but no sensitive data is recorded.
• Telemetry hook included; configure Sentry/monitoring DSN as needed.

Checklist:

• Wrap provider calls in try/catch and return structured error response
• Return HTTP 502 with OAUTH_PROVIDER_UNAVAILABLE / OAUTH_PROVIDER_ERROR
• Show readable error message in UI
• Add unit tests
• Add e2e test
• Add telemetry/logging statement

[raahulrahl]

@Suvam-paul145 where we are now?

[Suvam-paul145]

@raahulrahl please add apertre 3.0 and difficulty label

[Suvam-paul145]

@raahulrahl please add apertre 3.0 and difficulty label before merge

[JiwaniZakir]

The core issue is that unhandled promise rejections from OAuth provider calls (likely in frontend/src/lib/server/auth.ts) can cause the server to hang or return unformatted 5xx responses, leaving the UI in an indeterminate loading state. Without a try/catch boundary, a network timeout or DNS failure to the provider propagates as an uncaught exception rather than a structured response, which is why the frontend crashes or hangs instead of surfacing a recoverable error. Returning HTTP 502 with OAUTH_PROVIDER_UNAVAILABLE is the right signal here — it correctly distinguishes a third-party dependency failure from an internal server error (500), and gives the SignInButton component a clear contract to display the error toast. Worth confirming the error boundary in the UI also handles the case where the fetch to your own auth endpoint times out client-side, since a 502 may never arrive if the server itself is stalled waiting on the provider.