Error logging: Collect more context

[adamziel]

This recent report doesn't provide enough information to reproduce or reason about it"

What happened?
Not loading
Logs
[28-Mar-2024 02:42:03 UTC] Playground Error: RangeError: WebAssembly.instantiate(): Out of memory: Cannot allocate Wasm memory for new instance
Url
https://playground.wordpress.net/?url=/wp-admin/
playground.wordpress.netplayground.wordpress.net
[WordPress Playground](https://playground.wordpress.net/?url=/wp-admin/)
WordPress running in your browser for learning, testing, and

Let's also collect:

• Exact PHP and WP build IDs/versions (it's in the URL but new deployments happen each day)
• Type of a device, e.g. mobile phone
• Name and version of the web browser
• The number of open Playground tabs which we can do by asking the service worker – to figure out whether a single tab is exhausting the memory, or is it 5th
• Available memory – if JavaScript can even provide this information
• All error stack traces collected so far – there may be more than one

This would make it easier to reason about the incoming issues.

[flexseth]

Relevant tool proposal

• https://github.com/WordPress/wordpress-playground/issues/1164

[bgrgicak]

Available memory – if JavaScript can even provide this information

The best I could find is a non-standard deprecated API that works only in Chrome.

[bgrgicak]

All error stack traces collected so far – there may be more than one

@adamziel this goes back to the start of this project. Currently, we only collect PHP and WASM crash errors. To collect all errors we should either replace all console.... calls with custom functions, or override console... in the logger to collect all the info. Initially we decided to not do this, but seems like we want to do it now?

[bgrgicak]

All error stack traces collected so far – there may be more than one

@adamziel and I discussed this today and want to replace console.... calls with logger.. calls. By default all logs will be collected in the logger, but not exposed to the browser console. To expose logs in the console we will add a debug flag that can be controlled using the JS and query API. To view logs in the browser we will add a modal that will list all logs. The modal can be opened manually from the head menu, or in some cases, it will open automatically, for example, if a blueprint step fails.