| alaa | |
| Sep 3 2025, 7:01 PM |
| F65955248: 1.png | |
| Sep 3 2025, 7:01 PM |
Users on the Arabic Wikipedia have been complaining since yesterday evening about their inability to save edits through the visual editor, and that they are encountering an error message "Invalid response from server".
You can try this by opening any article on the Arabic Wikipedia, then trying to edit it in the visual editor, and then saving your changes. You'll receive the above error message in either Arabic or English (depending on the interface).
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | PRODUCTION ERROR | DLynch | T403656 "Invalid response from server" rarely appearing when attempting to save edits | ||
| Resolved | PRODUCTION ERROR | Esanders | T403745 ve.track module isn't loaded when launching 2017 editor on a page with discussiontools enabled |
This has been happening on enwiki too for me when using the 2017 wikitext editor. As soon as I reload it tends to resolve itself. You can see an example console error for it in P82432. (I don't know why it's formatted so weird; it looked like that in the browser console too.) Judging by that, it seems like it could be related to WikimediaEvents.
Also discussed at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#"Invalid_response_from_server"_when_editing_source_on_my_User_talk_pages
I was not able to reproduce.
Note that "Invalid response from server" may be misleading, that error message can also be shown as a result of JavaScript exceptions (like those in P82432).
I just got this now, on MW.org — but when I disabled uBlock Origin Lite it worked, and re-enabling the blocking breaks it again. Possibly the edit save API call is getting blocked? I don't see an HTTP 4xx (or whatever) on the POST however.
Unfortunately, reloading the page did not help resolve the issue.
It can reproduce easily in Arabic Wikipedia.
Yeah, this is due to a client JS exception. I just got a breakpoint down, so I can now confirm this is during editAttemptStep.js 's handleInitEvent. This means that handleFirstEvent is never getting called, meaning that editAttemptStepHandler isn't getting called. So maybe editAttemptStep isn't getting hit when it should be?
I am using an ad blocker which does block Wikimedia trackers so that does seem like a plausible cause.
I can confirm when the issue occurs that editAttemptStepHandler is never called, and it is called when the edits do save. It seems like it commonly (always?) happens when, on a talk page, I use "edit section" and then try to save some new text.
Edit: It looks like on 1) page load of a talk page (I dunno how much this generalizes to other pages) that getEditModeFromUrl returns null, causing this branch to not be taken. Then, if I click edit section, the document ready closure that that line of code is in (from line 1459) is never hit again. Then after I've clicked "edit section" if I do a reload we have the ready closure run again which correctly gets the edit mode and calls trackActivateStart, leading to the session object getting set. This might not be strictly relevant though because this whole file hasn't been touched in eight weeks, and there's many other places that .track editAttemptStep.
I'm elevating the priority of this to Unbreak Now! as this issue seems to be preventing a non-trivial population of people from saving edits.
Okay, so, specifically what I can reproduce is, if you edit a page with discussiontools enabled using the 2017 source editor, the dynamically-loaded source editor from clicking "edit source" won’t track any editatemptstep events. This causes a failure when a bit of code that expects there’s no way for the session to not exist errors in the pre-save requests.
Reloading the page appears to fix it because you’re then directly loading an action=editsource URL, which won’t be loading discussiontools underneath.
I can't reproduce an equivalent failure inside VE on arwiki.
Change #1184615 had a related patch set uploaded (by DLynch; author: DLynch):
[mediawiki/extensions/WikimediaEvents@master] EditAttemptStep: don't error if something is blocking session logging
@Jdforrester-WMF I think that your experience with adblocking may be suggestive of other situations that'd result in this particular error. Anything that stops ve.track from talking to mw.track would ultimately cause this.
Change #1184618 had a related patch set uploaded (by Jforrester; author: DLynch):
[mediawiki/extensions/WikimediaEvents@wmf/1.45.0-wmf.17] EditAttemptStep: don't error if something is blocking session logging
Change #1184619 had a related patch set uploaded (by Jforrester; author: DLynch):
[mediawiki/extensions/WikimediaEvents@wmf/1.45.0-wmf.16] EditAttemptStep: don't error if something is blocking session logging
Change #1184615 merged by jenkins-bot:
[mediawiki/extensions/WikimediaEvents@master] EditAttemptStep: don't error if something is blocking session logging
Change #1184618 merged by jenkins-bot:
[mediawiki/extensions/WikimediaEvents@wmf/1.45.0-wmf.17] EditAttemptStep: don't error if something is blocking session logging
Change #1184619 merged by jenkins-bot:
[mediawiki/extensions/WikimediaEvents@wmf/1.45.0-wmf.16] EditAttemptStep: don't error if something is blocking session logging
Mentioned in SAL (#wikimedia-operations) [2025-09-04T01:01:11Z] <kemayo@deploy1003> Started scap sync-world: Backport for [[gerrit:1184618|EditAttemptStep: don't error if something is blocking session logging (T403656)]], [[gerrit:1184619|EditAttemptStep: don't error if something is blocking session logging (T403656)]]
Mentioned in SAL (#wikimedia-operations) [2025-09-04T01:06:13Z] <kemayo@deploy1003> jforrester, kemayo: Backport for [[gerrit:1184618|EditAttemptStep: don't error if something is blocking session logging (T403656)]], [[gerrit:1184619|EditAttemptStep: don't error if something is blocking session logging (T403656)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.
Mentioned in SAL (#wikimedia-operations) [2025-09-04T01:13:18Z] <kemayo@deploy1003> Finished scap sync-world: Backport for [[gerrit:1184618|EditAttemptStep: don't error if something is blocking session logging (T403656)]], [[gerrit:1184619|EditAttemptStep: don't error if something is blocking session logging (T403656)]] (duration: 12m 07s)
Lowering priority now that the inability to save edits is fixed.
The underlying issue will manifest itself now as us not getting any instrumentation from these edit sessions, so we should work out exactly what's going wrong with the module-loading.
The issue has been resolved on the Arabic Wikipedia, and other users there have confirmed this to me. I've also tried it myself, and it seems to no longer be an issue with save changes via the visual editor.
I've split out the underlying ve.track loading issue into T403745, so we can consider this task to have been entirely about the interruption of saving.
QA steps: