Just in case there's a real bug here, I dug in a bit..

I grabbed the failing artifacts from: https://github.com/GoogleChrome/lighthouse/actions/runs/7415363551

And set a breakpoint in NetworkAnalysis, then ran node cli '-A=/Users/cjamcl/Downloads/Smokehouse (ubuntu; chrome stable)/2/dbw/' http://localhost:10200/dobetterweb/dbw_tester.html

the summary for this origin is all 0

Though we do have a RTT for it

Back to the summary timings - We only have one entry for the [::1] domain, which gets capped to 0 in _estimateResponseTimeByOrigin:

And that RTT estimate comes from one sample (we only have one network record for this origin...), which comes from this estimation:

(protocol is http/1.1 btw)

I guess this code is pretty flawed for n=1 samples, but I'm not sure how exactly or if it extends to when there are more samples. We could try adding another request to this domain, but that may just be masking a problem.

from my understanding, this being zero makes sense to me because: we must guess RTT w/ the worse case data, no SSL timing and just one sample. then we must derive the "server thinking time" which is the ttfb minus the rtt...and if this is all from the same record that's just not enough info to get what we want.

Yeah seems like a response time of 0 makes sense in this scenario. Doesn't seem like a problem, it just doesn't match the expectation for the other domain.