mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 09:25:06 +03:00
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 -->
127 lines
4.0 KiB
Plaintext
127 lines
4.0 KiB
Plaintext
---
|
|
id: 'functions-status-codes'
|
|
title: 'Status codes'
|
|
description: 'Edge Functions can return following status codes.'
|
|
subtitle: 'Understand HTTP status codes returned by Edge Functions to properly debug issues and handle responses.'
|
|
---
|
|
|
|
When invoking an Edge Function, the response may return a variety of HTTP status codes. The most common status codes are listed below.
|
|
|
|
<Admonition type="note">
|
|
|
|
Error responses may also include an `sb-error-code` header that identifies the specific error condition. See [Error Codes](/docs/guides/functions/error-codes) for a complete list of error codes and their meanings.
|
|
|
|
</Admonition>
|
|
|
|
## Success Responses
|
|
|
|
### 2XX Success
|
|
|
|
Your Edge Function executed successfully and returned a valid response. This includes any status code in the 200-299 range that your function explicitly returns.
|
|
|
|
### 3XX Redirect
|
|
|
|
Your Edge Function used the `Response.redirect()` API to redirect the client to a different URL. This is a normal response when implementing authentication flows or URL forwarding.
|
|
|
|
---
|
|
|
|
## Client Errors
|
|
|
|
These errors indicate issues with the request itself, which typically require changing how the function is called.
|
|
|
|
### 401 Unauthorized
|
|
|
|
**Cause:** The Edge Function has JWT verification enabled, but the request was made with an invalid or missing JWT token.
|
|
|
|
**Solution:**
|
|
|
|
- Ensure you're passing a valid JWT token in the `Authorization` header
|
|
- Check that your token hasn't expired
|
|
- For webhooks or public endpoints, consider disabling JWT verification
|
|
|
|
### 404 Not Found
|
|
|
|
**Cause:** The requested Edge Function doesn't exist or the URL path is incorrect.
|
|
|
|
**Solution:**
|
|
|
|
- Verify the function name and project reference in your request URL
|
|
- Check that the function has been deployed successfully
|
|
|
|
### 405 Method Not Allowed
|
|
|
|
**Cause:** You're using an unsupported HTTP method. Edge Functions only support: `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, and `OPTIONS`.
|
|
|
|
**Solution:** Update your request to use a supported HTTP method.
|
|
|
|
---
|
|
|
|
## Server Errors
|
|
|
|
These errors indicate issues with the function execution or underlying platform.
|
|
|
|
### 500 Internal Server Error
|
|
|
|
**Cause:** Your Edge Function threw an uncaught exception (`WORKER_ERROR`).
|
|
|
|
**Common causes:**
|
|
|
|
- Unhandled JavaScript errors in your function code
|
|
- Missing error handling for async operations
|
|
- Invalid JSON parsing
|
|
|
|
**Solution:** Check your Edge Function logs to identify the specific error and add proper error handling to your code.
|
|
|
|
```tsx
|
|
// ✅ Good error handling
|
|
try {
|
|
const result = await someAsyncOperation()
|
|
return new Response(JSON.stringify(result))
|
|
} catch (error) {
|
|
console.error('Function error:', error)
|
|
return new Response('Internal error', { status: 500 })
|
|
}
|
|
```
|
|
|
|
You can see the output in the [Edge Function Logs](/docs/guides/functions/logging).
|
|
|
|
### 503 Service Unavailable
|
|
|
|
**Cause:** Your Edge Function failed to start (`BOOT_ERROR`).
|
|
|
|
**Common causes:**
|
|
|
|
- Syntax errors preventing the function from loading
|
|
- Import errors or missing dependencies
|
|
- Invalid function configuration
|
|
|
|
**Solution:** Check your Edge Function logs and verify your function code can be executed locally with `supabase functions serve`.
|
|
|
|
### 504 Gateway Timeout
|
|
|
|
**Cause:** Your Edge Function didn't respond within the [request timeout limit](/docs/guides/functions/limits).
|
|
|
|
**Common causes:**
|
|
|
|
- Long-running database queries
|
|
- Slow external API calls
|
|
- Infinite loops or blocking operations
|
|
|
|
**Solution:**
|
|
|
|
- Optimize slow operations
|
|
- Add timeout handling to external requests
|
|
- Consider breaking large operations into smaller chunks
|
|
|
|
### 546 Resource Limit (Custom Error Code)
|
|
|
|
**Cause:** Your Edge Function execution was stopped due to exceeding resource limits (`WORKER_RESOURCE_LIMIT`, previously it was `WORKER_LIMIT`). Edge Function logs should provide which [resource limit](/docs/guides/functions/limits) was exceeded.
|
|
|
|
**Common causes:**
|
|
|
|
- Memory usage exceeded available limits
|
|
- CPU time exceeded execution quotas
|
|
- Too many concurrent operations
|
|
|
|
**Solution:** Check your Edge Function logs to see which resource limit was exceeded, then optimize your function accordingly.
|