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.

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.

In T240316#5727603, @Ladsgroup wrote:

Potentially a train blocker.

Yes - train blocker imho.

For debugging:

Direct API query: https://www.wikidata.org/w/api.php?action=query&meta=userinfo&uiprop=blockinfo|groups|rights

QS OAuth query: https://tools.wmflabs.org/quickstatements/api.php?action=is_logged_in

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.

In T240316#5728232, @Lea_Lacroix_WMDE wrote:

@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

In T240316#5728232, @Lea_Lacroix_WMDE wrote:

@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.

Is @Multichill able to add 172.16.0.0/12 to https://www.wikidata.org/wiki/MediaWiki:Autoblock_whitelist ?

Added. Does it fix the issue?

In T240316#5728522, @Fnielsen wrote:

Is @Multichill able to add 172.16.0.0/12 to https://www.wikidata.org/wiki/MediaWiki:Autoblock_whitelist ?

In T240316#5728629, @Ladsgroup wrote:

Added. Does it fix the issue?

In T240316#5728522, @Fnielsen wrote:

Is @Multichill able to add 172.16.0.0/12 to https://www.wikidata.org/wiki/MediaWiki:Autoblock_whitelist ?

Unfortunately, it does not fix it.

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.

In T240316#5727749, @Bugreporter wrote:

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.

In T240316#5727527, @Magnus wrote:

"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.

In T240316#5728638, @Tohaomg wrote:

In T240316#5728629, @Ladsgroup wrote:

Added. Does it fix the issue?

In T240316#5728522, @Fnielsen wrote:

Is @Multichill able to add 172.16.0.0/12 to https://www.wikidata.org/wiki/MediaWiki:Autoblock_whitelist ?

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!

In T240316#5728908, @Douglasfugazi wrote:

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