OAuth "Token is invalid or revoked" errors lack identifying context in Sentry

Problem

We're seeing this warning in Sentry, logged from the credentials page (error example: LIGHTNING-227):

Token is invalid or revoked for environment 'main' for Gmail: %{error: "invalid_request", status: 401, details: %{status: 401, description: "Invalid Credentials"}}

The event gives us the OAuth environment name (main) and the client name (Gmail), but nothing that identifies which credential, user, or project triggered it. The request params and uri are also scrubbed by Sentry's default PII filtering, so there's no way to recover that context from the event itself.

In practice this means: when this error fires, we know a Gmail-based OAuth credential somewhere had its token rejected as invalid/revoked, but we have no way to trace it back to the affected user or credential to investigate or reach out.

Source

The warning is logged in lib/lightning_web/live/credential_live/generic_oauth_component.ex, in the handle_async(:userinfo, ...) clause that handles a 401 response from the OAuth provider's userinfo endpoint. At the point this log line executes, the LiveComponent already has the credential struct (including its id) in socket.assigns, passed down from the parent credential form component - it's just not included in the log message.

Suggested improvement

Enrich this log line (and likely the sibling OAuth error logs nearby in the same file, e.g. the "Invalid token for environment" and "Failed to fetch userinfo" warnings) with identifying context that's already available on the socket, such as the credential id and/or the associated project id. This would let us:

• Look up the affected credential/project directly from the Sentry event
• Distinguish one-off user token revocations from a systemic issue (e.g. many credentials failing at once, which would point to a Gmail-side or client-config problem rather than individual user action)

Worth checking whether other OAuth/credential error paths have the same gap, so we fix this as a pattern rather than a one-off.

Start in lib/lightning_web/live/credential_live/generic_oauth_component.ex at the handle_async(:userinfo, ...) clause for 401 responses, then inspect the nearby "Invalid token for environment" and "Failed to fetch userinfo" warnings. Use the credential data already present in socket.assigns and check related OAuth error paths; done means Sentry events identify the affected credential or project without exposing scrubbed request data.