apps/docs/content/troubleshooting/edge-function-500-error-response.mdx
A 500 from an Edge Function means one of two things.
If you received back the below message, then go to the JavaScript failure section:
Internal Server Error
If the body contained a custom message, or nothing at all, run the below query in Log Explorer after setting the time range:
select
console_logs.event_message,
cast(invocation_events.timestamp as datetime) as timestamp,
invocation_events.function_name
from
function_logs as console_logs
left join UNNEST(console_logs.metadata) as metadata on true
left join (
select
timestamp,
em.execution_id,
res.status_code,
req.pathname as function_name
from
function_edge_logs
left join UNNEST(metadata) as em on true
left join UNNEST(em.request) as req on true
left join UNNEST(em.response) as res on true
) as invocation_events
on metadata.execution_id = invocation_events.execution_id
where
invocation_events.status_code = 500
and metadata.level = 'error'
and metadata.event_type in ('Log', 'UncaughtException')
and console_logs.event_message like '%Error:%file:///%'
order by invocation_events.function_name, invocation_events.timestamp
limit 50;
Based on the output, go to the relevant section:
Somewhere in your function logic, you are returning a 500 response yourself:
return new Response(JSON.stringify(data), {
headers: { ...corsHeaders, 'Content-Type': 'application/json' },
status: 500, // <-- you set this
})
console.error() message before the code returns, so future occurrences leave a better trace.See: Error handling in Edge Functions
An unhandled JavaScript Error emerged during execution.
The function's log will produce an event_message with the error type. It may look like:
TypeError: Cannot read properties of undefined (reading 'some_func')
at Object.handler (file:///var/tmp/sb-compile-edge-runtime/source/index.ts:15:26)
at eventLoopTick (ext:core/01_core.js:175:7)
at async mapped (ext:runtime/http.js:246:20)
The first line tells you the error type and message. The stack trace points to the file and line number.
The Mozilla Foundation documents all error objects and what they mean:
ErrorAggregateErrorEvalErrorRangeErrorReferenceErrorSuppressedErrorSyntaxErrorTypeErrorURIErrorInternalErrorHowever, you can also review the below example cases for an idea of possible causes.
A TypeError occurs when any JavaScript datatype is misused. For instance, trying to execute a number as if it were a function would cause the error:
const some_num = 5
some_num() // TypeError: some_num is not a function
This issue often appears when working with returned objects from external APIs. One may assume a response has a certain shape, but if the value is actually null or undefined, using it without checking can lead to a TypeError.
const data = await req.json() // returns undefined if request body is empty
data.some_obj.some_val // TypeError: Cannot read properties of undefined
const { user_submission } = await req.json()
// checking value for appropriate datatype
if (typeof user_submission === 'undefined') {
return new Response(JSON.stringify({ message: 'Submission is empty. Please try again.' }), {
headers: { ...corsHeaders, 'Content-Type': 'application/json' },
status: 400,
})
}
// rest of code ...
One could use a try/catch/finally block to handle these errors:
try {
some_obj.some_func(); // TypeError: Cannot read properties of undefined
...
}
catch(err) {
// customize the error message
console.error('return object was misformatted:', err)
}
finally {
// add a custom error response for easier debugging
return new Response(JSON.stringify(
{ message: 'Could not parse return object' }),
{
headers: { ...corsHeaders, 'Content-Type': 'application/json' },
status: 500 // opt to customize the status code to better fit the situation
}
)
}
A ReferenceError occurs when one tries to reference a variable that does not exist in the code's scope. Often times caused by a typo or missing import.
For instance, if one tries to access a variable before it is defined, they will encounter the error:
let a = some_uninitialized_var // ReferenceError: some_uninitialized_var is not defined...
You explicitly threw an error somewhere in your code, or a third-party package did:
throw new Error('custom, unhandled error')
Alternatively, in a try/catch blocks, you may have augmented the standard error message:
try {
// induce reference error
const a = unitialized_var // ReferenceError...
} catch (error) {
console.error('custom error message...', error) // modifying the original error message
}
When you customize the error response, it's important to define an appropriate new message. It may also be worthwhile changing the default 500 code returned during errors to a value more reflective of the situation for easier debugging in the future:
...
catch (error) {
console.error('custom error message...', error) // modifying the original error message
return new Response(JSON.stringify(
{ message: 'Permissions error, please sign in' }),
{
headers: { ...corsHeaders, 'Content-Type': 'application/json' },
status: 401 // customizing the status code
}
)
}
A SyntaxError error occurs when Deno's grammatical rules are violated, such as failing to close a parenthesis:
console.log('unclosed' ; // Uncaught SyntaxError: missing ) after argument list
In most cases, syntax violations can be fixed by removing a typo. There is a special case that is common enough that it is worth providing an example over: CORS violations.
When making calls from a browser, such as FireFox or Chrome, the site will make an OPTIONS request before sending over the actual payload. This is a security mechanism done to prevent Cross-Site-Request-Forgery attacks. To satisfy the request, you need to have a CORS handler in place:
const corsHeaders = {
'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
}
Deno.serve(async (req) => {
// CORS handler: manages OPTIONS request
if (req.method === 'OPTIONS') {
return new Response('ok', { headers: corsHeaders })
}
})
Without the OPTIONS handler, requests from the browser will be misinterpreted, resulting in an Unexpected end of JSON input error log.
SyntaxError: Unexpected end of JSON input
at parse (<anonymous>)
at packageData (ext:deno_fetch/22_body.js:408:14)
at consumeBody (ext:deno_fetch/22_body.js:261:12)
at eventLoopTick (ext:core/01_core.js:175:7)
at async Object.handler (file:///var/tmp/sb-compile-edge-runtime/source/index.ts:5:20)at async mapped (ext:runtime/http.js:246:20)
The solution is to follow our guide on adding CORS support.
It is also important to note that if any error occurs before the CORS check can be satisfied, the browser may falsely report CORS as the reason a request failed:
// returns before the CORS check can be satisfied
return
if (req.method === 'OPTIONS') {
return new Response('ok', { headers: corsHeaders })
}
So, when encountering these errors, it is still important to check the logs or run the request outside the browser to make sure it is actually the primary factor and not a side-effect of a larger issue.