Stuck on warming up #13273
Comments
|
We are experiencing the same issue for most sites. We've tried different computers and profiles, Windows and Mac. Chrome versions: Version 94.0.4606.81 (Official Build) (64-bit) |
|
Reproduces on Chrome 95.0.4638.69 (Official Build) (64-bit) / Lighthouse 8.4.0. It works fine on some pages: And gets stuck on the "warming up" on others: Based on my statistic - it usally works on higher quality pages, and gets stuck on heavier pages, or the ones with lots of errors in js console. I also face exact same issue in Chrome 97.0.4682.3 (Official Build) dev (64-bit) |
|
Repro on canary 97.0.4689.0 https://www.enricofromrome.eu/edb6/ EDIT: tried it again, also hung but the above error didn't happen.
|
|
that "port close is not a function" error is suspicious but it should be harmless, given how it is handled: this class should define a close method to fix https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/front_end/entrypoints/lighthouse_worker/LighthouseService.ts;l=18?q=setUpWorkerConnection&ss=chromium |
|
we should wrap the webappmanifest+install errors base artifact collecting in the equivalent error handling that our main artifacts get . This should prevent the run from exiting fatally.Although, I'd expect even a fatal run to not hang forever. We catch and rethrow fatal errors here: lighthouse/lighthouse-core/runner.js Line 183 in a48d616 which the lighthouse worker should catch here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/front_end/entrypoints/lighthouse_worker/LighthouseService.ts;l=64;drc=59f68132b1b2d61464d39b050fd3ff157775fa7d but... we don't use tldr; we should fix two errors here, 1) don't allow base artifacts protocol timeouts to create fatal error 2) correctly recover from a fatal error in lighthouse worker. this CL is the root cause of both of these: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2697187 . My fix: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3258498 the root cause of the protocol timeout for "get installability errors" is still at-large. |
A previous CL[1] refactored this file, transforming some promise chaining into a try/catch. However, the final statement that actually kicks off Lighthouse was not await'd, so any fatal error is not handled as expected. Additionally, the same CL dropped the 'close()' no-op method on the Lighthouse port. This doesn't result in a user-facing error because Lighthouse dismisses any error that happens during the disconnect phase, but there is still an error message logged to console, which is misleading as there really isn't any harm done. [1] https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2697187 [2] GoogleChrome/lighthouse#13273 (comment) Bug: 968639 Change-Id: Icf41f3ed8c3cd993f1d9e4748b8aff394c0582a5 Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3258498 Commit-Queue: Connor Clark <cjamcl@chromium.org> Reviewed-by: Paul Irish <paulirish@chromium.org>
|
My impression is that it has to do with service worker and installation (no
problem with other similar sites without service worker) . Please notice
that on chrome it works and no errors appear in the console, in the past it
used to work on lighthouse with a good result.
Il mer 3 nov 2021, 01:57 Connor Clark ***@***.***> ha scritto:
… we should wrap the webappmanifest base artifact function in the equivalent
error handling that our main artifacts get
/~https://github.com/GoogleChrome/lighthouse/blob/a48d6166df82ce5e365d507b5b4f03f5a233cc69/lighthouse-core/gather/gatherers/web-app-manifest.js#L81
. This should prevent the run from exiting fatally.
Although, I'd expect even a fatal run to not hang forever. We catch and
rethrow fatal errors here:
/~https://github.com/GoogleChrome/lighthouse/blob/a48d6166df82ce5e365d507b5b4f03f5a233cc69/lighthouse-core/runner.js#L183
which the lighthouse worker should catch here:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/front_end/entrypoints/lighthouse_worker/LighthouseService.ts;l=64;drc=59f68132b1b2d61464d39b050fd3ff157775fa7d
but... we don't use await here
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/front_end/entrypoints/lighthouse_worker/LighthouseService.ts;l=62;drc=59f68132b1b2d61464d39b050fd3ff157775fa7d>
so it doesn't work :)
------------------------------
tldr; we should fix two errors here, 1) don't allow base artifacts
protocol timeouts to create fatal error 2) correctly recover from a fatal
error in lighthouse worker
the root cause of the protocol timeout for "get installability errors" is
still at-large.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#13273 (comment)>,
or unsubscribe
</~https://github.com/notifications/unsubscribe-auth/AB7CT55AVCXRXFRT7T2Z7RTUKCJGXANCNFSM5G4Q6ZRA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
Even with the above CL landed, LH still hangs at this point: Debugging shows that the target for the service worker is never resumed:
|
|
On https://todo.koolsol.app, URL : https://todo.koolsol.app/ |
|
The PWA uses indexeddb
Il ven 5 nov 2021, 13:30 Hugues Koolsol ***@***.***> ha
scritto:
… On https://todo.koolsol.app,
lighthouse ends correctly only if I uncheck "vider l'espace de stockage" (
~empty storage space )
I hope it helps !
URL : https://todo.koolsol.app/
Heure d'exécution : 5 nov. 2021, 13:12 UTC+1
Appareil : Émulation (Moto G4)
Limitation de bande passante réseau : 150 ms TCP RTT, 1 638,4 Kbps
throughput (Simulated)
Limitation du processeur : 4x slowdown (Simulated)
Version : devtools
User-agent (hôte) : Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.0 Safari/537.36
User-agent (réseau) : Mozilla/5.0 (Linux; Android 7.0; Moto G (4))
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4590.2 Mobile
Safari/537.36 Chrome-Lighthouse
Puissance processeur/mémoire : 1740
Version d'axe : 4.2.3
Generated by Lighthouse 8.5.0
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#13273 (comment)>,
or unsubscribe
</~https://github.com/notifications/unsubscribe-auth/AB7CT52P6DQWSW35D2UJ6Z3UKPE6JANCNFSM5G4Q6ZRA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
Actually, it uses only localstorage api and not indexedDb. |
|
It uses both local storage and indexeddb through a service worker, it does
it on start. I am afraid this is a lighthouse problem because the program
keeps working on chrome (android and Linux) and Firefox.
Il sab 6 nov 2021, 12:31 Hugues Koolsol ***@***.***> ha
scritto:
… Actually, it uses only localstorage api and not indexedDb.
But you are right if you consider that localstorage looks like indexedDb.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#13273 (comment)>,
or unsubscribe
</~https://github.com/notifications/unsubscribe-auth/AB7CT5ZUC2W3S5VZLLLSPKTUKUGZJANCNFSM5G4Q6ZRA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
At this address you can find an older release:
https://www.enricofromrome.eu/edb2/legmen.htm
The older release used only localstorage and doesn't get stuck on
lighthouse. The new release also has service worker, manifest and indexeddb.
Il giorno dom 7 nov 2021 alle ore 01:08 enrico de bernart <
***@***.***> ha scritto:
… It uses both local storage and indexeddb through a service worker, it does
it on start. I am afraid this is a lighthouse problem because the program
keeps working on chrome (android and Linux) and Firefox.
Il sab 6 nov 2021, 12:31 Hugues Koolsol ***@***.***> ha
scritto:
> Actually, it uses only localstorage api and not indexedDb.
> But you are right if you consider that localstorage looks like indexedDb.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#13273 (comment)>,
> or unsubscribe
> </~https://github.com/notifications/unsubscribe-auth/AB7CT5ZUC2W3S5VZLLLSPKTUKUGZJANCNFSM5G4Q6ZRA>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>
|
|
Tracking this in #13396, please follow there. |
A previous CL[1] refactored this file, transforming some promise chaining into a try/catch. However, the final statement that actually kicks off Lighthouse was not await'd, so any fatal error is not handled as expected. Additionally, the same CL dropped the 'close()' no-op method on the Lighthouse port. This doesn't result in a user-facing error because Lighthouse dismisses any error that happens during the disconnect phase, but there is still an error message logged to console, which is misleading as there really isn't any harm done. [1] https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2697187 [2] GoogleChrome/lighthouse#13273 (comment) Bug: 968639 Change-Id: Icf41f3ed8c3cd993f1d9e4748b8aff394c0582a5
FAQ
URL
https://www.enricofromrome.eu/edb6/
What happened?
Nothing happened: that is the problem! Stuck on warming up. It used to work in the past.
What did you expect?
Normal behavior
What have you tried?
Repeated day after. Incognito and not incognito window. Tagging different options.
How were you running Lighthouse?
Chrome DevTools
Lighthouse Version
Sorry, I could not reach the report.
Chrome Version
Version 95.0.4638.54 (Official Build) (64-bit)
Node Version
No response
OS
No response
Relevant log output
No response
The text was updated successfully, but these errors were encountered: