On 12 dec the app started crashing (Yd.prepareHeaders (file:///var/task/___netlify-bootstrap.mjs:2:99473))

Hi,

Our application is suddenly given the error on every page:

{
“errorType”: “TypeError”,
“errorMessage”: “Cannot read properties of undefined (reading ‘toString’)”,
“stack”: [
“TypeError: Cannot read properties of undefined (reading ‘toString’)”,
" at Yd.prepareHeaders (file:///var/task/___netlify-bootstrap.mjs:2:99473)“,
" at Yd.annotateFromRequest (file:///var/task/___netlify-bootstrap.mjs:2:98884)”,
" at Yd.onRequestCreate (file:///var/task/___netlify-bootstrap.mjs:2:100758)“,
" at Channel.publish (node:diagnostics_channel:141:9)”,
" at new Request (node:internal/deps/undici/undici:7396:27)“,
" at [http1 build request] (node:internal/deps/undici/undici:7497:16)”,
" at [dispatch] (node:internal/deps/undici/undici:8609:139)“,
" at Client.Intercept (node:internal/deps/undici/undici:8289:20)”,
" at Client.dispatch (node:internal/deps/undici/undici:6872:44)“,
" at [dispatch] (node:internal/deps/undici/undici:7103:32)”
]
}, locally everything still works fine when reaching the same data. Did something change in netlify?

Where can we see this error happen? Mind sharing any URLs?

Hi Hrishikesh,

The error is from our logs for Function Next.js Server Handler.

The front-end error over at https://www.biobest.com/* is quite a bit less descriptive.

Best regards

The exact same thing happened to me on December 13th when deploying to the DEV environment, which consumes from the GitLab dev branch, and this behavior was replicated in PRO, which is from the main branch, without having made any code changes.

We experienced the same. Netlify unlisted our forum post (and another similar one) and created a zendesk ticket for us. Support seems at least as lost as we are. Something appears to be very broken and unlisting forum posts about it makes it look like they’re simply trying to sweep it under the rug rather than fix it or provide any real support.

@hrishikesh Is there any update on this?

Can confirm it’s an issue and it’s being worked on.


As for the concerns raised in this and other threads about unlisting them, this is intentional - not to hide or censor information, but we’re just following the guidelines that we’ve been told to follow.

Context:

The selling point of these forums was that, this was the only available means of support for free users. We used to not provide them any support in the helpdesk. A couple of months ago, we made a change that allows anyone to write in to the helpdesk. This was because, we are attempting to focus our time and efforts on providing support in a single platform.

Problem:

We couldn’t just get rid of the forums. It has a lot of historical data and search engine traffic that needs to be preserved. So the forums stayed and thus, new threads kept coming as well. This was going against our plan of spending efforts in a single platform.

Workaround:

We could have asked every new thread poster on the forums to open the same ticket in the helpdesk and we even did that for some time. But as you can imagine, it was just a lot more work for the customer.

Solution:

We created a staff-only button on the forums that does the following:

  • creates a ticket in the helpdesk
  • adds a link (which is supposed to be hidden, but looks like it’s being publicly posted for now, which will soon be fixed) to the ticket, so we can track the conversation (UPDATE: now fixed)
  • replies as a bot to the customer on the forums saying that the post has been escalated and they’d hear back over email.
  • since the forums thread is useless now as it only includes the problem’s description, but no real solution, we unlist and lock it so only the relevant threads remain active and indexable on the forums. Otherwise, it turns into a pond of useless information.

Maybe the solution is not ideal, but that’s what we currently have until a better solution comes in.

Also, some posts were unlisted and locked because they were just duplicates of this. Often times, users don’t search for existing posts and keep on adding new ones. We can’t go back to eeach thread and update it to say that the issue was fixed or something else. So to consolidate the communication, we link to the original thread, lock and unlist the duplicate one.

Anyone is free to think what they feel, including that “we’re just sweeping it under the rug”, but I tried to provide an explanation. I don’t expect anyone to agree with this approach, but we’re doing out best. :slight_smile:

Thank you for the confirmation. Given that the error has been present for at least 3 days and is application breaking, is there an ETA?

After downgrading the Node.js version from 22 to 20, our website appears to be up again so temporarily this can work for now but we would like to always be on the latest version where possible.

The devs mentioned that the issue has been fixed. If you downgraded your Node version in the last few minutes or so, it’s very likely that it was a coincidence.

In our case, we left the Node.js version at 20.x and our site has stabilized.