HttpServletResponse#sendError() dispatches to the error page immediately as soon as the method is called. This is wrong and has disatrous consequences when called inside a running servlet and the error page is mapped to the same servlet. Undertow must wait until all filters/servlets have returned from their service and only then dispatch the request to the error page (all other containers like Tomcat, GlassFish, JBoss AS, Geronimo, etcetera have always worked that way for ages).

Real world example: when the code executed by FacesServlet (JSF) calls sendError(), and the error page is a JSF page as well, then the request will be dispatched through the FacesServlet once again, causing all trouble in among others the threadlocal storage. Namely, when the sendError() returns, then all original threadlocal variables are lost, causing NPE over all place in the code running hereafter. JSF utility library OmniFaces tried to bypass this by putting the FacesContext back in TLS, but this is insufficient as JSF component libraries like PrimeFaces also have their own TLS variables: https://github.com/omnifaces/omnifaces/commit/b9badb86cb2112fd87485e060db21262de58887c

Here's the relevant section from Servlet 3.1 specification (page 111; emphasis mine):

10.9.3 Error Filters
The error page mechanism operates on the original unwrapped/unfiltered request
and response objects created by the container. The mechanism described in
Section 6.2.5, “Filters and the RequestDispatcher” may be used to specify filters that
are applied before an error response is generated.