Opaque, undebuggable stacktraces

[vedantroy]

Bug Description

When calling await r.json(), if the request text was not valid JSON, undici returns an opaque stacktrace which does not go to the line where the error was happening. This makes debugging near impossible.

Reproducible By

Write a fetch to an endpoint that does not return valid JSON. Then, call fetch("/endpoint").then(r => r.json())

Expected Behavior

An error thrown on the line where await request.json() was called.

Logs & Screenshots

Current behavior:

x-control-1      | SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSON                                         
x-control-1      |     at JSON.parse (<anonymous>)                                                                              
x-control-1      |     at parseJSONFromBytes (node:internal/deps/undici/undici:6662:19)                                         
x-control-1      |     at successSteps (node:internal/deps/undici/undici:6636:27)                                               
x-control-1      |     at node:internal/deps/undici/undici:1236:60                                                              
x-control-1      |     at node:internal/process/task_queues:140:7                                                               
x-control-1      |     at AsyncResource.runInAsyncScope (node:async_hooks:206:9)                                                
x-control-1      |     at AsyncResource.runMicrotask (node:internal/process/task_queues:137:8)                                  
x-control-1      |     at processTicksAndRejections (node:internal/process/task_queues:95:5)    

Environment

Node 20

[vedantroy]

This also happens when the fetch fails in general.

[ronag]

@mcollina

[mcollina]

I don't understand why that line is undebuggable: it seems pretty clear to me.

Is the problem the missing reference to where the call to fetch initiated?

I think this is due to the fact that we are not using the await operator in starting fetch. Wdyt @KhafraDev?

[KhafraDev]

it's because we use queueMicrotask here

undici/lib/fetch/util.js

Line 821 in c83b084

const successSteps = (bytes) => queueMicrotask(() => processBody(bytes))

, probably not much we can do? I also don't really see the value of debugging here because it's not an issue with undici.

[vedantroy]

Sorry for the lack of clarity here.

The lack of stacktrace is the issue. In a code-base with more than a few fetches, it becomes impossible to tell where the failed fetch occurred since it just gives the error and says nothing about where it originated in the code.

This does not happen with node-fetch, regardless of whether I use await or not.

[mcollina]

@KhafraDev I think we should be doing something for this, I think it can be very problematic for people.

[KhafraDev]

do you have any ideas? The queueMicrotask is needed for the spec (as close as a match we can get in node).

[mcollina]

you'd need to turn

undici/lib/fetch/util.js

Line 815 in c83b084

function fullyReadBody (body, processBody, processBodyError) {

into an async function and await readAllBytes. Then inside you'd need to await all those things. If you want to add a microtick, just doing await true would get you there (or await Promise.resolve(), then do await processBody(bytes)