@Gerges. Please log out and back in to reset your token. It is dangerous to post your token in screenshots since it can be used to impersonate you.

In T426539#11928899, @Novem_Linguae wrote:

@Gerges. Please log out and back in to reset your token. It is dangerous to post your token in screenshots since it can be used to impersonate you.

I've already logged out, but isn't this a temporary token for my session?

I'm not an expert on tokens. I just know you should never post them. So please be careful. An unexpired token can be used to do things logged in as you.

@SomeRandomDeveloper Could this be caused by some changes around T157658: Factor out a backend from EditPage?

Change #1288250 had a related patch set uploaded (by SomeRandomDeveloper; author: SomeRandomDeveloper):

[mediawiki/core@master] ApiEditPage: Update request in main context before calling attemptSave()

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

If this affects the workflow of a lot of people, I think we could also revert c58febaa602036d64f05ae1f831fe08caf321d97 on wmf.2 during the UTC afternoon backport window tomorrow (and on master if the core patch I uploaded doesn't get merged before tomorrow evening, so we don't need to backport anything to wmf.3).

In T426539#11929098, @SomeRandomDeveloper wrote:

If this affects the workflow of a lot of people, I think we could also revert c58febaa602036d64f05ae1f831fe08caf321d97 on wmf.2 during the UTC afternoon backport window tomorrow (and on master if the core patch I uploaded doesn't get merged before tomorrow evening, so we don't need to backport anything to wmf.3).

I don't think that's necessary. Last time it was broken for several weeks before it got reported and everyone was fine waiting for the deployment train to roll out the fix: T365334

In T426539#11929091, @SomeRandomDeveloper wrote:

Thanks for notifying me, I think this is caused by c58febaa602036d64f05ae1f831fe08caf321d97 (which is not related to the task you mentioned, but also a patch I made). When ApiEditPage is executed, it only updates $wgRequest and not the request in RequestContext::getMain(). AFAICT this only affects VisualEditor because it uses a DerivativeRequest to call action=edit internally when an edit is submitted.

I see, thanks for the fix!

In T426539#11929098, @SomeRandomDeveloper wrote:

If this affects the workflow of a lot of people

I’d guess reviewers are more likely to use the wikitext editor than newbies, so probably not an awful lot of people. Also, my experience as a reviewer is that I mostly review edits via other means than the edit form – if an unreviewed edit is okay, I just press the review button outside of the editor; this checkbox is helpful in the rarer case that an edit is mostly okay but needs some fixes.

Change #1288250 merged by jenkins-bot:

[mediawiki/core@master] ApiEditPage: Update request in main context before calling attemptSave()

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

Patch was reverted. Will need a different patch.

The fact that $wgRequest and RequestContext::getMain()->getRequest() hold two different requests during an API edit is a bug and will still need to be fixed eventually, but it will probably take a bit of work to fix code that uses this as a feature, since at least ConfirmEdit is apparently doing that (T426751). I think the best solution for next week's train is to just revert the FlaggedRevs patch for now until the ApiEditPage fix is reapplied at some point and confirmed to be working fine.

Change #1290042 had a related patch set uploaded (by SomeRandomDeveloper; author: SomeRandomDeveloper):

[mediawiki/extensions/FlaggedRevs@master] Revert "Replace all usages of $wgRequest"

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

Change #1290042 merged by jenkins-bot:

[mediawiki/extensions/FlaggedRevs@master] Revert "Replace all usages of $wgRequest"

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