546 - WORKER_LIMIT Exceeded

A 546 error indicates that an edge function used more resources (CPU or Memory) than it was allocated.

Context for the error#

Edge functions run in transient servers called isolates. Each isolate:

• Handles one request at a time
• Is bound to a single function (e.g. an isolate for func_one will never serve func_two)

When a request arrives, the runtime assigns it to a free isolate or spins up a new one if all existing isolates are busy. Each isolate also has resource limitations.

Once an isolate uses 50% of any resource, it will finish the current request and then shut down.

However, if that remaining request exhausts all CPU or memory before completion, the isolate will terminate immediately and return a 546 response.

Solving the error#

Step 1: Identifying the error#

When an edge function fails due to internal CPU or memory limits, it will return the error:

1
{
2
  "code": "WORKER_LIMIT",
3
  "message": "Function failed due to not having enough compute resources (please check logs)"
4
}

In the function dashboard's Logs tab, you can find the specific error message:

• Memory limit exceeded
• CPU Time exceeded

Alternatively, you can filter for the specific errors from the function using the log explorer

1
select
2
  fl.event_message,
3
  content.timestamp,
4
  fel.function_name,
5
  fel.status_code
6
from
7
  function_logs as fl
8
  left join UNNEST(fl.metadata) as content on true
9
  left join (
10
    select
11
      em.execution_id,
12
      req.pathname as function_name,
13
      res.status_code
14
    from
15
      function_edge_logs
16
      left join UNNEST(metadata) as em on true
17
      left join UNNEST(em.request) as req on true
18
      left join UNNEST(em.response) as res on true
19
  ) as fel
20
    on content.execution_id = fel.execution_id
21
where content.level = 'error' and fel.status_code = 546
22
order by timestamp, function_name
23
limit 20;

Step 2: Check error frequency#

Before optimizing, run the below query in the Log Explorer to understand how often 546s are occurring relative to total requests:

1
select
2
  COUNT(id) as total_responses,
3
  COUNTIF(response.status_code = 546) as total_546,
4
  SAFE_DIVIDE(COUNTIF(response.status_code = 546), COUNT(*)) * 100 as pct_546
5
from
6
  function_edge_logs
7
  cross join UNNEST(function_edge_logs.metadata) as metadata
8
  cross join UNNEST(metadata.response) as response
9
  cross join UNNEST(metadata.request) as request
10
where method != 'OPTIONS' and pathname = '/functions/v1/YOUR_FUNCTION_NAME';
11
-- <-- add your function name to inspect specific endpoints

Depending on the results, you may be able to determine if the event is an edge case or affecting a function's overall behavior.

Interpreting the results#

Step 2: Narrowing down the cause#

Experimenting locally#

The same constraints placed on edge function's hosted by Supabase are also imposed by the test environment spun-up by the CLI. You can follow the function's local development guide to set up a test environment and then serve your function locally:

1
supabase functions serve your-function --debug

Then try experimenting with different stress tests to see if you can induce 546s. Some tests worth trying may involve:

• sending a large payload
• testing varying paths or query parameters
• sending multiple requests at once

If you find a reliable way to induce the error, you may want to log between operations to gain more visibility or configure chrome dev-tools to pinpoint the underlying logic that is failing.

Exploring for failure patterns in the logs#

There are a few other queries that may be useful for identifying patterns around 546 errors.

Step 3: Correcting the error#

The only way to manage the error is to reduce resource consumption per request. There are a few strategies one can go about.

1. Refactor logic:#

If you believe a portion of your function is overly aggressive, try testing locally whether refactoring reduces resource overuse.

Common culprits:

CPU intensive recursions: intensive loops or recursion can quickly exhaust CPU

1
// This will exhaust CPU allocation when called repeatedly
2
function fib(n: number): number {
3
  if (n <= 1) return n;
4
  return fib(n - 1) + fib(n - 2); // high levels of recursion
5
}
6
7
for (let i = 0; i < 100; i++) {
8
  fib(40);
9
}

Unbounded memory allocation: filling large arrays in a tight loop prevents the garbage collector from freeing memory

1
// Each iteration allocates ~100s of KB. During the loops, all memory is consumed before GC can intervene
2
let ref = []
3
for (let i = 0; i < 1000; i++) {
4
  ref.push(new Array(10e4).fill('data'))
5
}

You can compare your function against working examples in the Edge Function docs for insight on how to rework your code.

2. Swap in a lighter package:#

If you're using a dependency that does more than you need, look for a lighter or more performant alternative.

3. Offload operations to the database:#

If you are performing logic to process data from Supabase Postgres, you may be able to handle the processing within the database directly by using database functions or refactored queries.

4. Offload operations to an external API:#

Instead of managing all operations within the function itself, there may be an external API that can execute CPU or memory intensive jobs on its behalf. One example would be using an external API for orchestrating a headless browser and then just using the edge function to manage the output of the activity instead of everything all in place.

5. Split operations into individual functions:#

Break a large function into smaller ones, each responsible for a single sub-task. Stitch the results together at the app level or via an orchestrating function.

6. Move to a less restrictive platform:#

Edge functions have a hard resource limit. If your work requires more resources than we permit, you can look into other solutions, such as AWS Lambda, that are less restrictive, or self-host edge functions and reconfigure the settings.

Example cases#

Image processing#

Performing edits against images or other large files can be both CPU and Memory intensive. Some approaches for reducing load is using more performant processing libraries, processing outside by using an API or the requester's server, or restricting the file size to reduce strain.

AI embedding generation and inference#

AI models process data into embeddings (large arrays), that they can more understand. Edge Functions are capable of managing some small models directly; however, some require more processing power than what the edge function can support directly. In these cases, the solution is to manage the embeddings via an external source, such as OpenAI, Anthropic, etc. and to just use the edge function for light processing and coordination.

Web scraping#

Web scraping often requires a headless browser operator, such as puppeteer or playwright for rendering web pages. In this case, it is better to use an external API to manage the headless browser for you and then parse the results it returns with the edge function. There's an example in the function docs: Taking Screenshots with Puppeteer

Additional resources#

• Edge Function shutdown reasons explained
• Monitoring resource usage
• Debugging Edge Functions