On further testing, sometimes I'm not provided a token at all in the link, while the slash doesn't seem to matter.

I suspect Timo is to blame...

%2B%5C is +\ like the api uses

Yup, we should hold off on any more deployments until we get this fixed.

I don't have this problem on my own testwiki.

It seems to have fixed itself on my test wiki...

Replicable on test2.wikipedia.org, but test.wikipedia.org seems fine...

Fixed by actually deploying r111695.

(Some odd caching issues seem to cause things to be still broken with ?debug=true , but fixed in production at this point. Debug mode issues should be examined separately.)

We embarked on a bugfixing mission to fix bug 34469 on Friday afternoon. This bug is a problem with adding and removing items from ones watchlist.

Several of us spent a lot of time looking at this issue. We thought this one was fixed by r111695, with there only being a problem with deployment of this file. After Andrew scap'd the entire tree to ensure we had a consistent environment, we found it more difficult to reproduce the problem, but still can in isolated instances.

The most peculiar part of this is that this seems to be dependent on which user is logged in. Aaron first discovered that he wasn't able to watch pages on enwikibooks, which RobLa confirmed. Erik had no problem watchlisting with his main account. We even tried logging in on each other's machines, and still witnessed the problem. Erik then discovered that he wasn't able to watchlist on eowiki.

RobLa was able to switch browsers from Chrome to Firefox, and have it work with an account that failed under Chrome.

What seems to be a reliable failure is appending ?debug=1 to the bug seems to reliably expose the issue (that is, it's always broken).

The common denominator when this fails is that mw.user.options fails to load, which is easily confirmed by calling mw.user.options.get() from the javascript console. This gets back to our old friend, bug 34409, which is a much bigger problem than just watchlists.

Bug 34409 is a blocker for 1.19, and we may need to roll back until we get this fixed.

With the passage of time and the kicking of the proxy caches that's happened, this bug has partially disappeared. (I can't reproduce it under normal conditions)

With debug=true, it still reproduces pretty reliably. However, it may not be dependent on bug 34409 after all. There is a valid mw.user.options and mw.user.token object. With debug=false, mw.user.tokens.values.editToken is "50bbcmumblemumblemumblemumble+\". With debug=true, mw.user.tokens.values.editToken is "+\"

(In reply to comment #10)

With debug=true, it still reproduces pretty reliably. However, it may not be
dependent on bug 34409 after all. There is a valid mw.user.options and
mw.user.token object. With debug=false, mw.user.tokens.values.editToken is
"50bbcmumblemumblemumblemumble+\". With debug=true,
mw.user.tokens.values.editToken is "+\"

With debug=true the tokens are served from bits.wikimedia.org, but the browser doesn't send the login cookie there, so the user is treated as anonymous, hence editToken === '+\'.

Per above, does this still need Highest/major?

(In reply to comment #12)

Per above, does this still need Highest/major?

Probably not. Leaving on the 1.19wmf1 milestone, though, since not having a reliable debug mode will probably bite anyone who is trying to diagnose a script problem, of which we should anticipate many given our current problems.

Resolved in r112052 by preventing user token and user options modules from being served through bits, which was causing them to give logged in users generic (cached) responses.