mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 01:45:10 +03:00
Miranda Limonczenko
7ce4ee53ae
Closes [DOCS-1289](https://linear.app/supabase/issue/DOCS-1289/get-the-linter-to-fix-what-it-flags-or-retirereplace-the-linter) Stacked on #50600, which points contributors at the authoring skills. Merge that one first. ## Problem Contributors experienced friction with the linter. They felt nickle and dimed for tiny nits and felt detracted from the work itself. PRs would become noisy with tiny one-word suggestions. Additionally, our homegrown linter is not very intelligent, causing frequent overrides. ## Solution This removes the linter entirely in favor of directing contributors to use SKILLS instead. The removal entails... - **CI.** Delete the three `docs_lint` workflows: the PR check, the external-PR comment companion, and the nightly `--fix` bot. Drop the stale `zizmor.yml` ignore entry for the deleted workflow. - **Tooling.** Delete `supa-mdx-lint.config.toml` and the 14 rule files. Drop the `lint:mdx` script and the `@supabase/supa-mdx-lint` dependency from docs, learn, and ui-library, and regenerate the lockfile. - **Content.** Remove the 181 directives. A separate commit carries Prettier's reformatting of the tables and blank lines those comments had suppressed, so the deletion commit stays readable. No prose changes. - **Style guide.** The word list states each rule directly instead of describing what the linter flagged. Every term survives, including the phrase groups that mirrored `Rule004ExcludeWords`. - **Skills.** `write-the-docs`, `edit-the-docs`, and `review-the-docs` drop `pnpm lint:mdx` from their self-review commands and check the word list directly. `ask-the-docs`'s CI reference drops both workflows. ## Manual testing 1. Run `git grep -i supa-mdx-lint -- . ':!pnpm-lock.yaml'`. No matches. 2. Run `pnpm install --frozen-lockfile --lockfile-only`. It passes, so the lockfile matches the three trimmed manifests. 3. Run `git diff master...HEAD --name-only --diff-filter=ACMR | grep -E '\.(md|mdx)$' | xargs npx prettier --config prettier.config.mjs --check`. All changed markdown passes. 4. Open the [reformatted filter table](https://docs-git-docs-retire-mdx-linter-supabase.vercel.app/docs/guides/observability/logs#filter-events) on the preview and compare it with [production](https://supabase.com/docs/guides/observability/logs#filter-events). The table renders the same. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Documentation guidance now uses manual prose and terminology review with the shared word list. * Clarified storage configuration and common Realtime channel mistakes. * Improved table formatting, text wrapping, and selected reference links. * Updated documentation authoring and review guidance. * **Chores** * Retired automated MDX linting from workflows and local validation commands. * Removed lint-suppression markers throughout documentation without changing instructions. * Added targeted documentation review guidance for pull requests. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
129 lines
6.2 KiB
Plaintext
129 lines
6.2 KiB
Plaintext
---
|
|
id: 'auth-error-codes'
|
|
title: 'Error Codes'
|
|
description: 'Supabase Auth Error Codes'
|
|
subtitle: 'Learn about the Auth error codes and how to resolve them'
|
|
---
|
|
|
|
## Auth error codes
|
|
|
|
Supabase Auth can return various errors when using its API. This guide explains how to handle these errors effectively across different programming languages.
|
|
|
|
## Error types
|
|
|
|
Supabase Auth errors are generally categorized into two main types:
|
|
|
|
- API Errors: Originate from the Supabase Auth API.
|
|
- Client Errors: Originate from the client library's state.
|
|
|
|
Client errors differ by language so do refer to the appropriate section below:
|
|
|
|
<Tabs
|
|
scrollable
|
|
size="small"
|
|
type="underlined"
|
|
>
|
|
<TabPanel id="javascript" label="JavaScript">
|
|
All errors originating from the `supabase.auth` namespace of the client library will be wrapped by the `AuthError` class.
|
|
|
|
Error objects are split in a few classes:
|
|
|
|
- `AuthApiError` -- errors which originate from the Supabase Auth API.
|
|
- Use `isAuthApiError` instead of `instanceof` checks to see if an error you caught is of this type.
|
|
- `CustomAuthError` -- errors which generally originate from state in the client library.
|
|
- Use the `name` property on the error to identify the class of error received.
|
|
|
|
Errors originating from the server API classed as `AuthApiError` always have a `code` property that can be used to identify the error returned by the server. The `status` property is also present, encoding the HTTP status code received in the response.
|
|
|
|
</TabPanel>
|
|
<$Show if="sdk:dart">
|
|
<TabPanel id="dart" label="Dart">
|
|
All errors originating from the `supabase.auth` namespace of the client library will be wrapped by the `AuthException` class.
|
|
|
|
Error objects are split in a few classes. `AuthApiException` is an exception which originates from the Supabase Auth API.
|
|
|
|
Errors originating from the server API classed as `AuthApiException` always have a `code` property that can be used to identify the error returned by the server. The `statusCode` property is also present, encoding the HTTP status code received in the response.
|
|
|
|
</TabPanel>
|
|
</$Show>
|
|
<$Show if="sdk:swift">
|
|
<TabPanel id="swift" label="Swift">
|
|
All errors originating from the `supabase.auth` namespace of the client library will be a case of the `AuthError` enum.
|
|
|
|
The `api(message:errorCode:underlyingData:underlyingResponse:)` case is a special case for errors which originates from the Supabase Auth API, this error always have an `errorCode` property that can be used to identify the error returned by the server.
|
|
|
|
</TabPanel>
|
|
</$Show>
|
|
<$Show if="sdk:python">
|
|
<TabPanel id="python" label="Python">
|
|
All errors originating from the `supabase.auth` namespace of the client library will be wrapped by the `AuthError` class.
|
|
|
|
Error objects are split in a few classes. `AuthApiError` is an error which originate from the Supabase Auth API.
|
|
|
|
Errors originating from the server API classed as `AuthApiError` always have a `code` property that can be used to identify the error returned by the server. The `status` property is also present, encoding the HTTP status code received in the response.
|
|
|
|
</TabPanel>
|
|
</$Show>
|
|
<$Show if="sdk:kotlin">
|
|
<TabPanel id="kotlin" label="Kotlin">
|
|
All exceptions originating from the `supabase.auth` namespace of the Kotlin client library will be a subclass of `RestException`.
|
|
|
|
Rest exceptions are split into a few classes:
|
|
|
|
- `AuthRestException` -- exceptions which originate from the Supabase Auth API and have a `errorCode` property that can be used to identify the error returned by the server.
|
|
- `AuthWeakPasswordException` -- an `AuthRestException` which indicates that the password is too weak.
|
|
- `AuthSessionMissingException` -- an `AuthRestException` which indicates that the session is missing, if the user was logged out or deleted.
|
|
|
|
All instances and subclasses of a `AuthRestException` have a `errorCode` property that can be used to identify the error returned by the server.
|
|
|
|
</TabPanel>
|
|
</$Show>
|
|
<$Show if="sdk:csharp">
|
|
<TabPanel id="csharp" label="C#">
|
|
All exceptions originating from the `supabase.Auth` namespace of the C# client library are wrapped by the `GotrueException` class.
|
|
|
|
`GotrueException` exposes:
|
|
|
|
- `StatusCode` -- the HTTP status code returned by the Supabase Auth API.
|
|
- `Reason` -- a `FailureHint.Reason` value that categorizes the error, so you can branch on it without parsing the message.
|
|
|
|
</TabPanel>
|
|
</$Show>
|
|
|
|
</Tabs>
|
|
|
|
## HTTP status codes
|
|
|
|
Below are the most common HTTP status codes you might encounter, along with their meanings in the context of Supabase Auth:
|
|
|
|
### [403 Forbidden](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403)
|
|
|
|
Sent out in rare situations where a certain Auth feature is not available for the user, and you as the developer are not checking a precondition whether that API is available for the user.
|
|
|
|
### [422 Unprocessable Entity](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422)
|
|
|
|
Sent out when the API request is accepted, but cannot be processed because the user or Auth server is in a state where it cannot satisfy the request.
|
|
|
|
### [429 Too Many Requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429)
|
|
|
|
Sent out when rate-limits are breached for an API. You should handle this status code often, especially in functions that authenticate a user.
|
|
|
|
### [500 Internal Server Error](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/500)
|
|
|
|
Indicate that the Auth server's service is degraded. Most often it points to issues in your database setup such as a misbehaving trigger on a schema, function, view or other database object.
|
|
|
|
### [501 Not Implemented](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/501)
|
|
|
|
Sent out when a feature is not enabled on the Auth server, and you are trying to use an API which requires it.
|
|
|
|
## Auth error codes table
|
|
|
|
The following table provides a comprehensive list of error codes you may encounter when working with Supabase Auth. Each error code is associated with a specific issue and includes a description to help you understand and resolve the problem efficiently.
|
|
|
|
<ErrorCodes service="auth" />
|
|
|
|
## Best practices for error handling
|
|
|
|
- Always use `error.code` and `error.name` to identify errors, not string matching on error messages.
|
|
- Avoid relying solely on HTTP status codes, as they may change unexpectedly.
|