-
Notifications
You must be signed in to change notification settings - Fork 268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash report collecting #996
Comments
@adamziel what do you think about collecting crash data in this way? |
This sounds perfect @bgrgicak, it would make identifying and fixing new issues a breeze. In a perfect world, it would auto-detect the same crash being reported earlier, and submit a new comment in an existing issue instead of always creating a new issue. |
Once we have a way to collect data, we can see if there is a way to generate unique names based on the error message. |
Yup! We can either do that ("error hash") OR compute similarity with other existing issues and treat everything below a threshold as a match. But you're right – we need some data first. We'll need a WASM source map, too, or otherwise the stack traces won't carry any usable information. Building PHP with source maps is supported since #639, but that also inflates the binary size. Ideally, we'd have a tiny WASM binary, a separately stored source map, and we'd have a way to recover the full debugging information from the minified stack trace. |
With #1102 merged this is now completed. Users can report errors on Playground.WordPress.net after Playground crashes, or manually from the menu. After reporting all errors are sent to Slack. More details can be found in the Playground documentation. |
To ensure Playground is stable, we need to understand when it fails, but we don't collect logs, so the only way is for someone to report an error to us.
We could add a crash report modal to the playground.wordpress.net site that would load whenever Playground crashes, additionally, there could be a button in the toolbar menu.
By allowing users to decide if they want to send the report or not, we would make the collection process transparent.
The modal would collect all relevant data like the debug.log, the error message that triggered the modal, the current blueprint, and URL.
To make reporting simple for us the modal could create a new GitHub issue.
The text was updated successfully, but these errors were encountered: