Page MenuHomePhabricator

Step 1: Improved generic error screen (impact: high)
Closed, ResolvedPublic13 Estimated Story Points

Assigned To
Authored By
Tonina_Zhelyazkova_WMDE
Dec 19 2019, 10:08 AM
Referenced Files
F31786394: image.png
Apr 29 2020, 9:21 AM
F31786385: image.png
Apr 29 2020, 9:21 AM
F31703088: Generic_2bts.png
Mar 26 2020, 10:28 AM
F31703091: Error_generic_Mobile_instructions_2bs.png
Mar 26 2020, 10:28 AM
F31691852: T241126_Desktop.png
Mar 19 2020, 12:39 PM
F31691853: T241126_Mobile.png
Mar 19 2020, 12:39 PM
F31690049: Generic_load.png
Mar 18 2020, 6:23 PM
F31690050: Generic_load_mobile.png
Mar 18 2020, 6:23 PM

Description

Problem:
The generic error screen that is shown when an error occurs during loading only says "An error occurred". We need to show them something more meaningful.

Screenshots/mockups:
Desktop

Generic_2bts.png (976×1 px, 48 KB)

Mobile

Error_generic_Mobile_instructions_2bs.png (1×750 px, 65 KB)

Please find specs in this Figma artboard.

Acceptance criteria:

  • generic error message is shown as in mock-ups whenever there is no specific error available
  • "report an error" link leads to a "create new task" page on Phabricator with Bridge tag filled in
    • can be configured to some other system for 3rd-party installs
    • if the reporting system doesn't support submitting details in the link then that can be omitted
  • include information necessary for debugging - e.g. stacktrace in the prefilled task form link (make sure first it doesn't reveal private information)
  • the message of the internal error object is shown
  • track the number of times each error is triggered
  • on clicking reload the Bridge is reloaded

Template for report:
Title: Wikidata Bridge error
Tag: Wikidata-Bridge
Content:
The error happened on: $articlename, $wikiname <- could also be $articleURL, whatever is easier
Item: $itemID
Property: $propertyID
Error message: $errormessage <- should make it clear that this was happening on load
Debug information: $stacktrace <- potentially shortened?

Event Timeline

Idea from @Michael:

give it [ErrorUnknown] the ApplicationErrors array as a prop and then dump the JSON.stringify of it into a <pre>.

Idea from @Michael:

give it [ErrorUnknown] the ApplicationErrors array as a prop and then dump the JSON.stringify of it into a <pre>.

Note: this has since been done in I969a22edc5.

darthmon_wmde renamed this task from Step 1: Improved generic error screen to Step 1: Improved generic error screen (impac: high).Mar 13 2020, 1:38 PM
Lydia_Pintscher renamed this task from Step 1: Improved generic error screen (impac: high) to Step 1: Improved generic error screen (impact: high).Mar 19 2020, 10:21 AM
Lydia_Pintscher updated the task description. (Show Details)
Sarai-WMDE renamed this task from Step 1: Improved generic error screen (impact: high) to Step 1: Improved generic error screen: on load (impact: high).Mar 19 2020, 12:39 PM
Sarai-WMDE updated the task description. (Show Details)
Lydia_Pintscher renamed this task from Step 1: Improved generic error screen: on load (impact: high) to Step 1: Improved generic error screen (impact: high).Mar 31 2020, 1:17 PM

"report an error" link leads to a "create new task" page on Phabricator with Bridge tag filled in

Does this link open in a new tab or in the same one?

"report an error" link leads to a "create new task" page on Phabricator with Bridge tag filled in

Does this link open in a new tab or in the same one?

New tab unless @Charlie_WMDE objects.

new tab seems sensible since we will be doing the same for the "on save" generic error screen and it would make sense to keep the behavior consistent.

The button here is labeled “Reload” whereas T244361: Step 1: Error messages: Edit conflict (on save) has “Reload page”. Is that difference intentional or should they both use the same message?

Template for report:

The error happened on: $articlename, $wikiname <- could also be $articleURL, whatever is easier

For the Phabricator task body template, we’re going with the article URL in T249119, since that seems more useful and is also easier to get. But what about the message shown to the user in the UI, where the article name and wiki name are also included? Can we also use the article URL there, or should that still be the title and wiki name? (And in that case, what exactly is the wiki name? Is it the general site name like “Wikipedia”, something like “English Wikipedia” (though I’m not sure if that’s actually defined anywhere), the db name like “enwiki”, or something else?)

The button here is labeled “Reload” whereas T244361: Step 1: Error messages: Edit conflict (on save) has “Reload page”. Is that difference intentional or should they both use the same message?

the difference is intentional. in one case we reload just the bridge, in the edit conflict case we reload the whole page so the change of the other person that caused the edit conflict becomes visible in the infobox.

Template for report:

The error happened on: $articlename, $wikiname <- could also be $articleURL, whatever is easier

For the Phabricator task body template, we’re going with the article URL in T249119, since that seems more useful and is also easier to get. But what about the message shown to the user in the UI, where the article name and wiki name are also included? Can we also use the article URL there, or should that still be the title and wiki name? (And in that case, what exactly is the wiki name? Is it the general site name like “Wikipedia”, something like “English Wikipedia” (though I’m not sure if that’s actually defined anywhere), the db name like “enwiki”, or something else?)

article URL would be fine for me.

Change 591778 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: ReportIssue: use entityTitle instead of entity id

https://gerrit.wikimedia.org/r/591778

Change 591778 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: ReportIssue: use entityTitle instead of entity id

https://gerrit.wikimedia.org/r/591778

The ticket talks about the "itemID" being part of the reported error, as well as the error message shown to the user.

For practical (technical) reasons we changed that ever so slightly. Instead of the "itemID" we use the item title (the title of the item on the repo). For wikidata this will result in no actual difference, on installations with a different configuration it results in the item namespace being part of that string, e.g. "Item:Q42" instead of "Q42". The template for the report was amended accordingly, reads "Item title:" instead of "Item:" as a consequence.

Documenting this here pro forma, but assuming it has no implications in the real world as long as the created reports give us meaningful, unambiguous insights.

Change 592691 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: reportIssueTemplateBody: use entityTitle

https://gerrit.wikimedia.org/r/592691

There is now a "defective link" on https://en.wikipedia.beta.wmflabs.org/wiki/Data_bridge to provoke a "generic error screen" as specified in this ticket.
Another way to provoke such an error (for UAT) could be to disable the network connection after loading the article and only then click on one of the (usually working) bridge-enabled links.

Change 592691 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: reportIssueTemplateBody: use entityTitle

https://gerrit.wikimedia.org/r/592691

Charlie_WMDE closed this task as Resolved.EditedApr 29 2020, 9:21 AM
Charlie_WMDE claimed this task.
Charlie_WMDE moved this task from Verification to Done on the Wikidata-Bridge-Sprint-18 board.

everything looks good except for the bottom button margin. it is currently 5px

image.png (152×239 px, 7 KB)

but should be 4px

image.png (142×572 px, 15 KB)

this is probably due to the different line height of 21px (which is according to the specs)
but after discussing with sarai this will be revisited as part of the visual fixes anyway, to make it match the new button sizes, so i'll just move this to done now since there's no point in changing it twice.