Page MenuHomePhabricator

Provide helpful information when publishing failed
Closed, ResolvedPublic1 Story Points

Description

After going through the publishing error logs, I see a handful of publishing failures because of the following reasons:

  • The user is blocked from editing in the target wiki
  • The content has URLs that triger spamblacklist.(fails with code spamblacklist)
  • Request timeout
  • A few parsoid 503s

Some of these can be fixed or can attept retry if the translator know the reason.
A small message on why publishing failed can be helpful compared to dead end "publishing failed" message after time taking translation process.

Details

Related Gerrit Patches:
mediawiki/extensions/ContentTranslation : masterProvide useful error details when publishing fails
mediawiki/extensions/ContentTranslation : masterAvoid providing Special:CX for blocked users

Event Timeline

santhosh created this task.May 27 2015, 8:52 AM
santhosh raised the priority of this task from to Needs Triage.
santhosh updated the task description. (Show Details)
santhosh added a subscriber: santhosh.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 27 2015, 8:52 AM
santhosh set Security to None.May 27 2015, 8:52 AM
santhosh added a subscriber: Pginer-WMF.
Amire80 triaged this task as High priority.May 28 2015, 1:17 PM
Amire80 moved this task from Needs Triage to CX6 on the ContentTranslation board.Jun 23 2015, 8:18 AM

Better error info would definitely help and it is already a step forward.
For specific issues we can also improve the experience even more. I have some questions that may help to define better strategies to deal with these errors:

The user is blocked from editing in the target wiki

We should try to check it as soon as the user tries to create a translation, not only after the user completed the work. Is there a way to check for user publishing capability?

The content has URLs that triger spamblacklist.(fails with code spamblacklist)

I was thinking about possible strategies, but I wanted to check:

  • Is it possible to surface a captcha and let the user continue if the captcha is solved?
  • Is it possible to identify which links are causing the problem and publish the content without those links (or even any external links if we are not sure which one is the culprit)? (e.g., "English Wikipedia identified some of your links as potential spam, do you want to publish the article without (those) external links?)
  • Can we identify the issue as external links are added (before publishing happens)?

Request timeout

Do we know if retrying has been working for users? In such case, it may make sense to make the initial retry automatically and expose the issue only if the issue persists.

A few parsoid 503s

Do we know from Parsing them which is the cause of those?

Arrbee edited a custom field.Jul 21 2015, 5:51 PM

Change 227190 had a related patch set uploaded (by Santhosh):
Avoid providing Special:CX for blocked users

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

Change 227190 merged by jenkins-bot:
Avoid providing Special:CX for blocked users

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

Change 227409 had a related patch set uploaded (by Santhosh):
Provide useful error details when publishing fails

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

santhosh moved this task from Backlog to In Review on the LE-CX6-Sprint 1 board.

Change 227409 merged by jenkins-bot:
Provide useful error details when publishing fails

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

Arrbee moved this task from In Review to Done on the LE-CX6-Sprint 1 board.Jul 29 2015, 7:11 AM

Blocked users can no longer access their drafts. This would probably be the first time blocking prevents read access to something, as opposed to write access only.

Blocked users can no longer access their drafts. This would probably be the first time blocking prevents read access to something, as opposed to write access only.

I created T107857 for a less restrictive solution for blocked users.

Arrbee added a subscriber: Arrbee.Aug 4 2015, 9:26 AM

Blocked users can no longer access their drafts. This would probably be the first time blocking prevents read access to something, as opposed to write access only.

Now tracked at T107858. Closing this current ticket.

Arrbee closed this task as Resolved.Aug 4 2015, 9:26 AM