Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring netlify-branded functions error page to edge functions #4655

Closed
1 task done
Skn0tt opened this issue May 31, 2022 · 6 comments · Fixed by #5070
Closed
1 task done

Bring netlify-branded functions error page to edge functions #4655

Skn0tt opened this issue May 31, 2022 · 6 comments · Fixed by #5070
Assignees
Labels
area: functions good first issue type: feature code contributing to the implementation of a feature and/or user facing functionality

Comments

@Skn0tt
Copy link
Contributor

Skn0tt commented May 31, 2022

Which problem is this feature request solving?

At the moment, when an edge function throws an uncaught exception, we just show the body of the 500 returned. The fact that an uncaught exception led to this is non-obvious.

Describe the solution you'd like

Instead, we should use the Netlify-branded error page that was introduced in #4486 also for edge functions. We've implemented a similar thing for production via https://github.com/netlify/stargate/pull/554, which uses the structured errors returned from edge functions via https://github.com/netlify/edge-functions-bootstrap/pull/38.

Pull request (optional)

  • I can submit a pull request.
@Skn0tt Skn0tt added the type: feature code contributing to the implementation of a feature and/or user facing functionality label May 31, 2022
@minivan
Copy link
Contributor

minivan commented Aug 15, 2022

From Slack:

I am assuming, just to clarify, that we mean setting this up for local development using netlify/cli?

The easiest way to reproduce this is to have a repo that has an edge function with an error, deploy the site, and invoke the function.

On a live site, we should see an error page.

If locally, we run netlify dev and invoke the function, we don't see the Netlify branded error page.

@khendrikse
Copy link
Contributor

I think I was a bit confused because @Skn0tt mentioned

We've implemented a similar thing for production via https://github.com/netlify/stargate/pull/554, which uses the structured errors returned from edge functions via https://github.com/netlify/edge-functions-bootstrap/pull/38.

But I guess the difference then is that this issue is not about those structured errors, but about uncaught exceptions?

@Skn0tt
Copy link
Contributor Author

Skn0tt commented Aug 15, 2022

In the first implementation of these error pages, we had full stack traces included in the error page, including for uncaught exceptions inside of user code. These were visible to all visitors, and disclosed both that the site is hosted by Netlify, and potentially leaked some source code internals (stacktraces contain file names, function names etc). So we've changed it so that the page itself shows only a bland error code like "Uncaught exception", and then there's a link at the bottom that leads to the edge functions log page. See https://edge-functions-examples.netlify.app/error for an example.

For the CLI though, I think we'd like to change that up a bit. Since there's no logs page to point towards, and we don't need to hide implementation details in local dev, I think it'd be fine to show the full stacktrace.

@Skn0tt
Copy link
Contributor Author

Skn0tt commented Aug 15, 2022

Here's some pointers towards what code we'd need to change:

In https://github.com/netlify/edge-functions-bootstrap/blob/2ca738749a57957640c9c8132f512810ebc79d88/src/bootstrap/handler.ts#L38-L43, we'd need to add a "local dev" mode that returns not only String(error), but also error.stack and other metadata.

Then in the local-dev codebase, we'd need to check for the x-nf-uncaught-error error, and render the existing error page template.

@khendrikse
Copy link
Contributor

So if I understand correctly, this is already solved then for production?

But it needs to also be implemented on local dev so we can see details of what is going wrong when developing?

@eduardoboucas
Copy link
Member

@khendrikse this marked as "In progress". Can you share an update?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: functions good first issue type: feature code contributing to the implementation of a feature and/or user facing functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants