next.js
next.js copied to clipboard
500 error page throws client-side exception if it has a getStaticProps and there is a middleware.ts file
Verify canary release
- [X] I verified that the issue exists in the latest Next.js canary release
Provide environment information
Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:37 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T6000
Binaries:
Node: 16.13.2
npm: 8.7.0
Yarn: 1.22.15
pnpm: 6.11.0
Relevant packages:
next: 12.2.3-canary.12
eslint-config-next: N/A
react: 18.2.0
react-dom: 18.2.0
What browser are you using? (if relevant)
n/a
How are you deploying your application? (if relevant)
using next start
Describe the Bug
In production, if my app has a 500.tsx file that has getStaticProps exported and it also has a middleware.ts file, and the URL visited contains a query parameter, the app will throw a client-side exception after rehydrating, but before any ErrorBoundary defined in _app could catch it.
The 500 page is first correctly rendered serverside, then is replaced by this message in the browser:
Application error: a client-side exception has occurred (see the browser console for more information).
A number of superfluous requests seem to be being made:

The issue only exists on 12.2 and above, it works correctly if I downgrade to 12.1.6 and convert back to the pre-release middleware usage. When the url did not have a query parameter, this issue was resolved in 12.2.4.
Expected Behavior
I expect to see the static error page render successfully.
Link to reproduction
https://codesandbox.io/s/gifted-alex-0hlens?a=b
To Reproduce
- create a pages/500.ts file that has a getStaticProps
- create a middleware.ts file, it does not need to do anything (but also tested with always returning a NextResponse.next())
- throw in pages/index.ts when visiting the page with a query parameter
Hey guys. Having the exact same problem on https://estudeprisma.com/d/matematica. Can anyone give us some help here?
This seems to have been resolved with 12.2.4-canary.1 and above
Reopening as it seems this issue is not fully resolved, in the case the url contains a query parameter. The above reproduction still produces the issue with latest canary: https://0hlens.sse.codesandbox.io/?a=b
@gazs I am experiencing the exact same issue under the same conditions. There is a middleware in place and the 500 page uses getStaticProps but somehow it throws a client-side error:
"Unhandled Runtime Error" "Error: Failed to load static props"
When I use a basic middleware file which returns Response.next(), the same error occurs. When I remove the middleware file the page starts working again.
@gazs I am experiencing the exact same issue under the same conditions. There is a middleware in place and the 500 page uses getStaticProps but somehow it throws a client-side error:
"Unhandled Runtime Error" "Error: Failed to load static props"
When I use a basic middleware file which returns Response.next(), the same error occurs. When I remove the middleware file the page starts working again.
I believe we are also experiencing this when no query parameters are set, correct? @clarkeverdel
@jobveldhuis Yes indeed.
Was looking for this. Seems fixed from v12.3+
v12.3.0 does not seem to have fixed the issue for us. The issue @clarkeverdel mentioned is still happening:
- Using middleware
- Using
getStaticProps
- Without query parameters
- Client side error:
Error: Failed to load static props
- Both in
dev
andbuild
mode
Same issue here. we have a global error-handling middleware
Page.getInitialProps = async (props) => {
const { res, err, req } = props
const statusCode = err ? err.statusCode : res ? res.statusCode : null
return { statusCode }
in the network tab, the response contains the expected status code. but after the first render, client-side is rendering 500 error for some reason
Same issue. deleting the middleware file for test purposes would render the custom 500 error page as expected without throwing errors on client side.
Issue is still happening on next 12.3.1
, the custom 500 page is still showing the error on the browser console after what it seems a few duplicated GET requests to the page that was throwing the error.

My middleware file is just a rewrite for a one of the paths
export async function middleware(req: NextRequest) {
const { pathname } = req.nextUrl;
if (pathname == '/') {
const url = req.nextUrl.clone();
url.pathname = '/lists';
return NextResponse.rewrite(url);
}
return NextResponse.next();
}
And my 500.tsx get static props is just for grabbing the locales
export const getStaticProps = async ({ locale }: { locale: string }) => ({
props: {
...(await serverSideTranslations(locale, ['common'])),
},
});
help for me
This seems to still be happening. Did anyone find a solution? 🤔 🙏
We have the same problem in version 12.3.1
I have the same issue. Only for page /500
because if I used the same code but for /toto
, it worked.
I solved it in 12.3.1, by ignoring middleware for 500 page
matcher: [
/*
* Match all request paths except for the ones starting with:
* - api (API routes)
* - _next/static (static files)
* - _next/image (image optimization files)
* - favicon.ico (favicon file)
* - 500 page
*/
'/((?!api|_next/static|_next/image|favicon.ico|500).*)',
]
For our case, this is sufficient
I have the same problem, "next": "^14.1.0", pages directory
I solved it in 12.3.1, by ignoring middleware for 500 page
matcher: [ /* * Match all request paths except for the ones starting with: * - api (API routes) * - _next/static (static files) * - _next/image (image optimization files) * - favicon.ico (favicon file) * - 500 page */ '/((?!api|_next/static|_next/image|favicon.ico|500).*)', ]
For our case, this is sufficient
Mm what do you mean? What if i go to any page that throws 500 error, in your middleware you don't intercept it, since the url would be /any_other_page_with_500_error and not /500 or am i missing something?
@federicocappellotto97
sorry for late response, yes you are right, i forgot to mention you have to redirect manually in your getServerSideProps.
try { }
catch (e) {
captureMessage(e);
return {
redirect: {
destination: "/500",
permanent: false
}}}
its not optimal , but we dont have so many getServerSide routes, so best what i got. If you found some other solution, let me know.