core: add top-level runtimeError

[brendankenny]

@paulirish

Here's one simple approach to #5881. All artifact errors are caught, and any deemed runtimeError worthy are floated to the top-level property in the LHR. From that bug, this handles

2. tracing result failures: NO_tracing_start, no_navstart, NO_FCP, no_dcl = FATAL
3. Screenshot/speedline errors = all fatal. (unless its a pain. no big deal, really)

It sort of handles

1. defaultPass pageload error = runtimeError
   • 500'd. 400'd. certificate error. network disconnected / offline.
   • FAILED_DOCUMENT__REQUEST, NO_DOCUMENT__REQUEST

but if that pageload error affects enough audits (which it usually does) we throw from the whole Lighthouse run and don't ever return an LHR.

Like the idea mentioned in #5881 (comment), I'd prefer to continue throwing exceptions for these cases and then checking outside core in runLighthouseForLR that the thrown error has lhrRuntimeError set on it. Most of our clients just want a thrown error in those cases, not a pseudo-LHR, and dealing with a pseudo-LHR just makes tracking the LHR type and what's on it messier when we really just want an exception floated up.

So I don't think it's worth doing that inside core. In runLighthouseForLR we can create that pseudo-LHR with just the top-level runtimeError property.

Doing it that way will completely handle (1) above and

3. tracing recording failures: TRACING_ALREADY_STARTED, PARSING_problem, read_failed, (timeout_during_trace_retreival)
   if you're still good with that idea.

If this is 👍 from you I can add that and tests.

[brendankenny]

lol no

[paulirish]

awesome. this matches what we need. :)

CI needs golden lhr update

[paulirish]

I was thinking we're returning a psuedo LHR so one more level on top of this:

return JSON.stringify({runtimeError}, null, 2);

[brendankenny]

yeah I missed that.

[brendankenny]

ok, ready for review @paulirish :)

[paulirish]

looks so great. all lgtm except for one question on throwing in ext-bg

[paulirish]

In this situation I think we should not throw but instead return an "UNKNOWN_ERROR" i guess.

tbh i dont know what throwing does in this context. my guess is its not caught and triggers a timeout?

[brendankenny]

tbh i dont know what throwing does in this context. my guess is its not caught and triggers a timeout?

well it would throw and be up to the caller to deal with, but we can do UNKNOWN_ERROR instead :)

[brendankenny]

done

[paulirish]

so so good. \o/

🍳🍳🍳