Where is this happening? wfm.

I reproduced it, but it went away after I did a pull and reloaded the editor. So... either weird and situational, or fixed by something subtle in the last day-ish. (Nothing in that timeframe looks relevant, though.)

I was getting it on Beta cluster and just found it happening on test2 too. This time I had the editor open for a while before adding any link.
But yes, it didnt happen anymore after I saved the edit and reloaded the editor.

Problem here is that the CSRF token the editor's using for API calls times out, and it doesn't handle this gracefully. Or... it handles it sort of gracefully, in that it doesn't die outright.

{"error":{"code":"badtoken","info":"Invalid CSRF token.","*":"See http://dev.wiki.local.wmftest.net:8080/w/api.php for API usage."}}

It's also not just adding a link -- it's anything which the editor needs to make a visualeditoredit/serialize call for (i.e. anything which makes it pop up that momentary progress dialog).

Can we make visualeditoredit/serialize not require a token? API docs say it's just for data-modifying calls.

Change 336439 had a related patch set uploaded (by DLynch):
ArticleTarget: try to refresh editToken if getWikitextFragment fails

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

I did take a look at whether it'd be easy to have just serialize not require a token in ApiVisualEditorEdit.php. It wouldn't. Could make a new serialize method in ApiVisualEditor.php and migrate usage to that, of course, if it really doesn't require any data-saving.

In the meantime, the provided patch does some refactoring in ArticleTarget, so that the existing token refresh done when a save attempt fails with badtoken can be reused here, without any API changes needed.

Change 336439 merged by jenkins-bot:
ArticleTarget: try to refresh editToken if getWikitextFragment fails

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