Page MenuHomePhabricator

Tracking of generic save errors
Closed, ResolvedPublic

Description

In order to know which errors need to receive more specific handling, we would like to track how often different kinds of save errors happen. The details of this task are not decided yet, and it ties in with the ongoing discussion at T249120: Add tracking of errors.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 8 2020, 1:29 PM

Change 593220 had a related patch set uploaded (by Tonina Zhelyazkova; owner: Tonina Zhelyazkova):
[mediawiki/extensions/Wikibase@master] bridge: Add tracking for generic errors on save

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

Change 593220 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: Add tracking for generic errors on save

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

Tonina_Zhelyazkova_WMDE closed this task as Resolved.May 4 2020, 10:36 AM

Do we close this task now, or should it also include tracking more error kinds than just SAVING_FAILED?

Do we close this task now, or should it also include tracking more error kinds than just SAVING_FAILED?

My impression was that we summarize all saving errors under this one. If we need to make the tracking more explicit, then we need to teach our application to recognize different server responses. That doesn't seem to be part of this task in particular.
What other errors do you have in mind?

Well, the task description says that

In order to know which errors need to receive more specific handling, we would like to track how often different kinds of save errors happen.

So far, we don’t track any different kinds of save errors – we only know how many save errors happen overall. That’s why I thought that splitting them (into edit conflict, server read-only, network error, assertuser failed, etc.) could be considered part of this task.

Well, the task description says that

In order to know which errors need to receive more specific handling, we would like to track how often different kinds of save errors happen.

So far, we don’t track any different kinds of save errors – we only know how many save errors happen overall. That’s why I thought that splitting them (into edit conflict, server read-only, network error, assertuser failed, etc.) could be considered part of this task.

Agreed that it would be beneficial to track those type of errors you listed. Some of them are on our board, so I think the tracking of these errors should be implemented in the respective task.
E.g., if we are to implement edit conflict error tracking as part of this task, it's not going to be triggered until there is an edit conflict error screen developed.
It is another matter if these separate tasks mention tracking in their AC.