it's a security thing to not leak senstive data to the client. You can't disable it. You can use the included digest id to check your serverside logs why there is an error. You will get additional details with the digest id. So check the server side logs and resolve the error

that error is IN server side logs

Making them entirely useless to solve this problem

Also, if I run my local build with NODE_ENV=development npm start - I don't get the error

This is maybe the 7th time in the last month that I've had errors in production that are an absolute nightmare to debug, because they don't happen in development mode

Something needs to be done here

(Is there some secondary log to look in to?)

I might just go back to pages router - it was slower, and harder to use for some things, but at least it worked as expected

This is the error you want to fix: https://nextjs.org/docs/messages/dynamic-server-error

(I'm also pretty sure someone back ported a change from next 15 to 14.2, which disables the default caching behavior for fetch - I just had to manually add cache rules for every fetch request, to avoid blowing my CPU budget - not cool)

"Example of Incorrect Usage" - uses cookies - I don't use cookies, or any of these other APIs (also, I could rant about the Meteor.js like "magic" API side effects, configuring the behavior of the server - this is not wonderful)

Apologies, I'm going to get a muffin. Clearly I'm hangry. I appreciate the help.

did u try exluding errors in the compiler config?

I don't get compile errors - these happen in production, at runtime

Wow, you need to chill a little bit… of course that’s annoying, but dude chill… that makes me angry as well

no in the config of the compiler that removes all error logs at build time so it doesnt show up in the console

Okay, muffin in. Some constructive feedback:
- "Magic" configuration based on API usage (from side effects) without some kind of logging, is just not scalable. It confuses teams who probably don't all understand the deeper consequences of using various APIs, and is hard to maintain.
- If we are going to use side-effects to drive configuration, we should at least enable some kind of reporting (especially during development). There is already a "logging" key which is used to enable (very useful) fullUrl output with cache notes for fetch requests. Expand that to also output information about the current configured (from side-effects) state for an accessed URL (in dev mode - this is important).
- While we are at it, let's enable some output to explain when you are successfully using side-effects to configure a static or dynamic route. I'm currently trying to define static reoutes, which are filled through ISR - I'm acutally not even sure this is a supported pattern. I just know it works in dev mode, and in production builds, when running with NODE_ENV=development - which is bonkers (that's a technical term)
- But really - let's add a non-side-effects mode. Require every route be statically configured through the various configuration options. Some flag to set which requires explicit (and correct) route configuration would be outstanding. You could use side-effects to test those, and output warnings in dev mode. Now there's no "magic" - this would be better. Like 10,000% better.

This ([and other problems which go unanswered](https://github.com/vercel/next.js/discussions/65856)) has brought my high traffic standalone deployment down for an entire weekend. And I've spent now a week trying to figure out what the cause of it was - and it's likely something from a minor version bump (4.1.x to 14.2.x) - calling this frustrating is an understatement. It really makes me question the reliability of next.js when not running on Vercel (and my company has a Vercel enterprise account)

This frustration isn't out of the blue - like I said, I've hit at least 7 different production only bugs in the last month...

That's a cool setting! But it probably wouldn't help in this case.

I guess you are a very experienced developer and as one you should know that there are bugs, there will be bugs and there were bugs in the past. So enjoy, that you learning something new 😊

The muffin is helping lol

BTW, this is fantastic

I had this error once (thankfully only once), because also for me it was really annoying. I think I also solved it here in help-Forum. So if you need to find the solution take a look at my messages (of course filter them lol)

So, basically, as long as I flesh out the generateStaticParams array, it works fine

Which is annoying - in pages router, leaving that array empty was perfectly viable

And it saves a BUNCH of time and resources on startup, since you don't have to render all those pages (hundreds in my case) to the static cache

I honestly wish next.js would deprecate the "compile" time static generation altogether

We have ISR - let that do the work

Maybe thousands

let's see 300 unique slugs, * 50 US state, * another 50 (compare state) - 750,000 ROFLMAO

Let me go back to basics - is this supposed to work?

export const generateStaticParams = () => {
  return [];
};

if you just want static pages that are not pre genearted, but these pages also load dynamically, why don't you add force-static to the top?

If the page is first loaded the dynamic part will be fetched and a static file is generated. The static file will be served and displayed. Either stay here or if you need to change something (dynamic part), just revalidate the page 🙂

is it:

export const dynamic = "force-static";

yea

I recall some discovery someone did on the team - where that setting does not cause next.js to output appropriate headers unless you also specify generateStaticParams - I'll give it a try though

lmk if it works

well this is fun - might explain (yet)another problem I've been having:

^C^C^C^C^C^C^C(node:84992) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 close listeners added to [Server]. Use emitter.setMaxListeners() to increase limit
(Use `node --trace-warnings ...` to show where the warning was created)

The fetch requests failed because the tunnel I had set up dropped. Does next.js automatically retry failed requests?

i dont think so

no soup

Here's one thing I just noticed - it's jumping all the way out of app router, back to the old pages router layout when the error happens in app router

r u using both? app AND pages router? 🤔

Yeah, we've been migrating to app router

There's very little left in pages router

but our legacy API is still in there

I'm going to try to remove the legacy page routes and layout support, and see if I get different errors

oh ok 👍

sigh, I get these useless errors:
redacted

That's just not useful for anything

It could be sentry, let me rip that out

Removing sentry deobfuscated the chunks - but it's still not useful:

TypeError: Invalid URL
    at new URL (node:internal/url:775:36)
    at F (/Users/kevin.newman/repos/project/.next/server/chunks/5527.js:135:1575)
    at eh (/Users/kevin.newman/repos/project/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:134786)
    at e (/Users/kevin.newman/repos/project/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:137671)
    at ek (/Users/kevin.newman/repos/project/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:138145)
    at Array.toJSON (/Users/kevin.newman/repos/project/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:135755)
    at stringify (<anonymous>)
    at eR (/Users/kevin.newman/repos/project/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:142219)
    at eE (/Users/kevin.newman/repos/project/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:142698)
    at Timeout._onTimeout (/Users/kevin.newman/repos/project/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:135475) {
  code: 'ERR_INVALID_URL',
  input: '',
  digest: '3472048596'
}

I mean, this is clearly broken, right?

Well, now it's failing even with NODE_ENV=development npm start - progress!

It does use my custom error layout, while it wasn't before (just a black error 500 screen)

I have to guess, but I'd guess ERR_INVALID_URL means that next.js doesn't think the incoming request URL is valid for some reason - probably becuse it's not in the array from generateStaticParams

EFF me, there is a use of headers() in my route....

I really can't describe how much I dislike this "auto" mode crap, based off side effects

And also, the inability to inspect search params, and the need for hacks like forwarding that stuff through headers in middleware

This is aggrivating to an extreme

And on top of that, I can't just set some response headers, so that cloudfront will cache the damn thing

Which would solve all my problems

ANY GET request should be cacheable

it's baffling why a search param would disable cacheable requests to this extreme

(to clarify, I'm using middleware to capture search params, and put them in headers to pass on to page handlers... Why? Because next.js.)

This is such a stupid problem - it would be a 10 second solution on litertally any other app platform

Honestly, that problem, with a host of other recent basic quality issues in next.js has me seriously questioning it’s use for anything more than static brochureware. I mean, this is a serious limitation - I'm not even sure the next devs understand how limiting this is.

How to fix all this:
- Get rid of side-effect driven "magic" config - accessing headers, or whatever, should not change the way the page handler fundamentally works. Ever. Replace it with direct, explicit configuration. The bones are there already - just make this a mode, or even default. No more magic. Can still use side-effects to validate some edge cases - if you use headers, you are creating a vary-by situation, in static generation, etc. This could be used to produce some helpful dev mode output.
- Enable vary-by - in http, there is already a standard for this type of thing. If you need to inspect headers to create varied output, that's fine. The vary-by header (or similar in next.js's ISR cache) should be able to handle this.
- To that end, get rid of static generation all together. Use runtime ISR. If you want something similar to static cache generation at startup, add a cache warming system (the bones again, are there - convert generateStaticParams to warm ISR, not have a separate static disk cache).
- For the love of all that matters in life, let us use search params to vary the static output, with caching, with cache headers - all that. Query params are GET requests - they should be cacheable. There are too many cases where you need a bit of information to vary some output, but it doesn't quite fit in a route structure. Search params work for that, and there's no good reason that can't be cached like anything else.
- (Or at least add some very clear logging to tell you what mode you are in)
- When all else fails, let us control the headers for a page route.