Page MenuHomePhabricator

Issue with QuickStatements "you are blocked on Wikidata"
Closed, ResolvedPublic

Description

This task describe an issue that several user encounter since 9.12.19.

While using QuickStatements, they are blocked in their workflow by an error message "you can't create a new batch because you are blocked on Wikidata". These users are not blocked on Wikidata.

A few impacted users:

  • user:Douglasfugazi
  • user:Jason.nlw
  • user:Jane023
  • user:Ahoerstemeier
  • user:John_P._Sadowski_(NIOSH)
  • user:SCIdude
  • user:B25es

Other facts:

  • The old QuickStatements interface seems to work
  • QuickStatementsBot is indeed blocked on Wikidata at the moment
  • SourceMD and Petscan apparently also not working (to be confirmed)

Possible reasons:

  • QuickStatementsBot is blocked since October 28th, 2019. We assume it was not a problem because most of the work coming from QuickStatements is made through the individual users' account through OAuth. It may be that a problem with OAuth occured, redirecting the batches to the bot's account, which is blocked.
  • internal issue with QuickStatements
  • some change in the permissions or maxlag on Wikidata (unlikely: no change in this direction has been made recently)

Reported on: Project Chat, Help:QuickStatements, Twitter, Telegram.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 10 2019, 8:20 AM
Lea_Lacroix_WMDE updated the task description. (Show Details)
Lea_Lacroix_WMDE updated the task description. (Show Details)
Jane023 added a subscriber: Jane023.

I noticed this late last night and had been using QS all day. I just switched to the old interface and that is still working. So something must have happened around dinner time? Like 6-9 PM GMT or Western European time.

Jklamo added a subscriber: Jklamo.Dec 10 2019, 9:37 AM

I have same issue with "new interface", old interface works without any problem.

A possible unrelated issue is Magnus Manske's sourcemd that is also in non-working condition. https://twitter.com/MagnusManske/status/1204000679116849152

Hi i'm impacted.

Thanks all for your feedback. Can you somehow check, in your QS interface, if the edits are about to be made with your individual account or the QuickStatementsBot account? Eg if the OAuth authentication worked or not?

I did not touch QS for weeks. No idea why this is happening.

Did something change with OAuth on WMF side?

Also, I wasn't really aware QuickStatementsBot is blocked. It used to do some automated SourceMD edits. SourceMD needs an overhaul anyway, so no big thing, and unlikely to be related.

I can't create batches either, so good for testing!

No to the OAuth issue - OAuth is visibly logged in. I cannot even paste into the window to get the import loaded so I am unable to answer the rest of your question. All edits (before and after with old interface) are correctly logged under my userid.

I think I found the reason. Using MW API to get user info, I get:

{
  "id": 4420,
  "name": "Magnus Manske",
  "blockid": 15320,
  "blockedby": "Mahir256",
  "blockedbyid": 203574,
  "blockreason": "আপনাকে স্বয়ংক্রিয়ভাবে বাধা দেওয়া হয়েছে, কারণ আপনার আইপি ঠিকানাটি সম্প্রতি \"[[User:Doqume|Doqume]]\" ব্যবহার করেছেন। Doqume-কে বাধাদানের কারণ \"Freebald-ish behavior\"",
  "blockedtimestamp": "2019-12-09T16:59:04Z",
  "blockexpiry": "2019-12-10T16:59:04Z",
  "groups": [
    "rollbacker",
    "*",
    "user",
    "autoconfirmed"
  ],
  "rights": [
    "autopatrol",
    "editsemiprotected",
    "move",
    "autoconfirmed",
    "skipcaptcha",
    "abusefilter-log-detail",
    "suppressredirect",
    "read",
    "edit",
    "createpage",
    "createtalk",
    "writeapi",
    "translate",
    "item-term",
    "property-term",
    "item-merge",
    "item-redirect",
    "abusefilter-view",
    "abusefilter-log",
    "flow-hide",
    "reupload-own",
    "move-rootuserpages",
    "move-categorypages",
    "minoredit",
    "purge",
    "applychangetags",
    "changetags",
    "reupload",
    "upload",
    "flow-edit-post"
  ]
}

But I am not blocked; editing works fine.

So basically the API is sending wrong information? Weird. @Ladsgroup could you have a quick look and see if you can reproduce?

I seem to be getting the block for [[User:Doqume]] on Wikidata, but for every user

BTW, old interface does not work either, but it fails to edit only after importing commands and pressing "Run"

If I check the API directly in the browser, it doesn't show. Maybe because OAuth login?

It's not a stale cache on my side. If I get different properties from https://www.wikidata.org/w/api.php?action=help&modules=query%2Buserinfo I get the requested properties but still the bogus block.

I can't check right now but for whoever is debugging, this is very likely regression from wmf.8 that got deployed yesterday. (List of patches that got deployed)

Potentially a train blocker.

Just want to mention that not all users are affected:

https://www.wikidata.org/wiki/Special:RecentChanges?tagfilter=OAuth+CID%3A+1351&limit=500&days=30&enhanced=1&urlversion=2

I was just able to load and execute a batch with the "new" QS tool in a newly loaded tab (I have sysop rights at Wikidata). User:Mahir256 can edit as well (another Wikidata sysop), and User:Alicia_Fagerving_(WMSE) (not a sysop) can also edit with QS.

Potentially a train blocker.

Yes - train blocker imho.

Actually the reason is QuickStatements use a single IP to edit on behalf of different users, so once a QuickStatement user is blocked other is autoblocked.

Therefore the toolforge IP range should be added to https://www.wikidata.org/wiki/MediaWiki:Autoblock_whitelist. we have 10.0.0.0/8 in the list, but the IP range of Labs is now 172.16.0.0/12.

@Bugreporter That seems unlikely. QuickStatementsBot is blocked since October 28th, and daily users of the tool only started reporting this issue yesterday.

B25es updated the task description. (Show Details)Dec 10 2019, 2:53 PM

@Bugreporter That seems unlikely. QuickStatementsBot is blocked since October 28th, and daily users of the tool only started reporting this issue yesterday.

I mean autoblock of the account Doqume, not QuickStatementsBot

@Bugreporter That seems unlikely. QuickStatementsBot is blocked since October 28th, and daily users of the tool only started reporting this issue yesterday.

The edits don't use QuickStatementsBot, that block seems unrelated.

Maybe one user who has used QS via QAuth was blocked, and now that IP (range?) is blocked for QAuth?

User:Doqume is blocked, the autoblock still exists.

Added. Does it fix the issue?

Added. Does it fix the issue?

Unfortunately, it does not fix it.

Bugreporter added a comment.EditedDec 10 2019, 5:07 PM

Consider remove autoblock from User:Doqume (see https://www.wikidata.org/wiki/Special:Blocklist)

I can't check right now but for whoever is debugging, this is very likely regression from wmf.8 that got deployed yesterday. (List of patches that got deployed)

In terms of timeline for yesterday's rollout of wmf.8, from production SAL (times UTC):

23:00 	<brennen@deploy1001> 	Synchronized php-1.35.0-wmf.8/extensions/Cite: Sync [[gerrit:556066|Hotfix: Defensive array accesses (T240248)]] (duration: 00m 57s)
22:55 	<brennen@deploy1001> 	rebuilt and synchronized wikiversions files: all wikis to 1.35.0-wmf.8
18:01 	<brennen@deploy1001> 	rebuilt and synchronized wikiversions files: Revert "group2 wikis to 1.35.0-wmf.5"
17:52 	<brennen@deploy1001> 	rebuilt and synchronized wikiversions files: all wikis to 1.35.0-wmf.8
17:09 	<brennen@deploy1001> 	Synchronized php: group1 wikis to 1.35.0-wmf.8 (duration: 01m 00s)
17:08 	<brennen@deploy1001> 	rebuilt and synchronized wikiversions files: group1 wikis to 1.35.0-wmf.8

So hitting group1 at 17:09 probably lines up with this.

brennen triaged this task as Unbreak Now! priority.Dec 10 2019, 5:19 PM
Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptDec 10 2019, 5:19 PM
Restricted Application added a project: Core Platform Team. · View Herald TranscriptDec 10 2019, 5:42 PM
Anomie added a subscriber: Anomie.

Actually the reason is QuickStatements use a single IP to edit on behalf of different users, so once a QuickStatement user is blocked other is autoblocked.
Therefore the toolforge IP range should be added to https://www.wikidata.org/wiki/MediaWiki:Autoblock_whitelist. we have 10.0.0.0/8 in the list, but the IP range of Labs is now 172.16.0.0/12.

This appears to be correct.

"blockid": 15320,

That is the ID of an autoblock on 172.16.1.157 (tools-worker-1039.tools.eqiad.wmflabs) triggered by this block, as others have guessed.

Added. Does it fix the issue?

Unfortunately, it does not fix it.

It may be that that will prevent future autoblocks, but the existing autoblock would still have to be undone.

Fixed. QuickStatements is working now :) Thanks a lot!

Fixed. QuickStatements is working now :) Thanks a lot!

Interesting, because I removed the block for autoblock #15320 about 1 minute later according to the logs
https://www.wikidata.org/wiki/Special:Log/Mbch331

Agusbou2015 closed this task as Resolved.Dec 10 2019, 11:07 PM

Added all reserved IPs for private network to the whitelist to avoid cases like that in the future.

Restricted Application added a project: User-Ladsgroup. · View Herald TranscriptDec 11 2019, 11:31 AM
Maintenance_bot moved this task from Incoming to In progress on the User-Ladsgroup board.
Maintenance_bot moved this task from In progress to Done on the User-Ladsgroup board.