Change Details

**Prio Meeting Notes** We want to look at the errors, and provide some overview / breakdown of the current situation and errors that occur. We should write phabricator tickets for these errors and put them in the general #wikidata backlog. Any errors deemed to be bad enough and within the realms of our code would then be brought back into the prioritization sessions for pickup. Some of the tickets that we create may be for code that we do not own or control (such as gadgets). We still want to create these tickets so that the community has an opportunity to fix the issues. **ACs:** [] Wikidata.org Errors have been reviewed [] We know the source of the errors [] We have phabricator ticket for the errors that we want to fix **Original write up** Following up on T255585 I've setup a dashboard for tracking client errors at: https://logstash.wikimedia.org/goto/0e48f48aaeb915d759f53eedc4230000 This filters various known gadget problems to allow you to focus on the errors that matter. Right now wikidata seems to cause more errors than any other project that has error tracking enabled - about 8,988 errors in the last 24 hrs -we should strive to get these down to 5000 a day to be at similar levels to the other projects. @esanders has created a useful tool for shortening stack traces that may be useful: https://edg2s.github.io/short-trace/ From experience, anything with a count of over 200 in 12hrs is probably something worth fixing. Troublesome IP addresses usually indicate a faulty user script that is also worth fixing to cut down log noise. The biggest priority should be diagnosing and fixing the error `TypeError: context is undefined ` Let me know if I can help with anything relating to triage or the dashboard itself! Have fun!

Following up on T255585 @jdlrobson has setup a dashboard for tracking client errors at: https://logstash.wikimedia.org/goto/0e48f48aaeb915d759f53eedc4230000 We want to look at the errors, and provide some overview / breakdown of the current situation and errors that occur. We intend to define the process/ways of addressing different kind of errors. This will follow once the overview of the error landscape is created. We might want to write phabricator tickets for these errors and put them in the general #wikidata backlog. Some of the tickets that we create may be for code that we do not own or control (such as gadgets). We still want to create these tickets so that the community has an opportunity to fix the issues. **Information to include in the overview** (potentially incomplete list) * source of the error (at least Wikibase code, non-Wikibase Mediawiki, gadget) * frequency of occurrence (e.g. with the weekly window) **ACs:** [] Wikidata.org Errors have been reviewed [] We know the source of the errors [] We have phabricator ticket for the errors that we want to fix **Original write up** Following up on T255585 I've setup a dashboard for tracking client errors at: https://logstash.wikimedia.org/goto/0e48f48aaeb915d759f53eedc4230000 This filters various known gadget problems to allow you to focus on the errors that matter. Right now wikidata seems to cause more errors than any other project that has error tracking enabled - about 8,988 errors in the last 24 hrs -we should strive to get these down to 5000 a day to be at similar levels to the other projects. @esanders has created a useful tool for shortening stack traces that may be useful: https://edg2s.github.io/short-trace/ From experience, anything with a count of over 200 in 12hrs is probably something worth fixing. Troublesome IP addresses usually indicate a faulty user script that is also worth fixing to cut down log noise. The biggest priority should be diagnosing and fixing the error `TypeError: context is undefined ` Let me know if I can help with anything relating to triage or the dashboard itself! Have fun!

**Prio Meeting Notes**Following up on T255585 @jdlrobson has setup a dashboard for tracking client errors at: https://logstash.wikimedia.org/goto/0e48f48aaeb915d759f53eedc4230000 We want to look at the errors, and provide some overview / breakdown of the current situation and errors that occur. We should write phabricator tickets for these errors and put them in the general #wikidata backlog. Any errors deemed to be bad enough and within the realms of our code would then be brought back into the prioritization sessions for pickupintend to define the process/ways of addressing different kind of errors. This will follow once the overview of the error landscape is created. We might want to write phabricator tickets for these errors and put them in the general #wikidata backlog. Some of the tickets that we create may be for code that we do not own or control (such as gadgets). We still want to create these tickets so that the community has an opportunity to fix the issues. **Information to include in the overview** (potentially incomplete list) * source of the error (at least Wikibase code, non-Wikibase Mediawiki, gadget) * frequency of occurrence (e.g. with the weekly window) **ACs:** [] Wikidata.org Errors have been reviewed [] We know the source of the errors [] We have phabricator ticket for the errors that we want to fix **Original write up** Following up on T255585 I've setup a dashboard for tracking client errors at: https://logstash.wikimedia.org/goto/0e48f48aaeb915d759f53eedc4230000 This filters various known gadget problems to allow you to focus on the errors that matter. Right now wikidata seems to cause more errors than any other project that has error tracking enabled - about 8,988 errors in the last 24 hrs -we should strive to get these down to 5000 a day to be at similar levels to the other projects. @esanders has created a useful tool for shortening stack traces that may be useful: https://edg2s.github.io/short-trace/ From experience, anything with a count of over 200 in 12hrs is probably something worth fixing. Troublesome IP addresses usually indicate a faulty user script that is also worth fixing to cut down log noise. The biggest priority should be diagnosing and fixing the error `TypeError: context is undefined ` Let me know if I can help with anything relating to triage or the dashboard itself! Have fun!