For example, try to load the global watchlist while you are not logged in on one of the watched sites. The API will return a notloggedin error, and the page will throw a GlobalWatchlist error, please check the console! alert that leaves the page in a broken state. A more reasonable approach would be to load the data from all the sites that work, and show a warning box listing the sites that didn't.
Description
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add handling for API failures when fetching watchlist | mediawiki/extensions/GlobalWatchlist | master | +107 -49 |
Related Objects
Event Timeline
(Also ideally the tool would use a method that does not depend on login cookies, such as a centralauthtoken request.)
Currently this uses the mw.ForeignApi, which, if CentralAuth is installed, should be using centralauthtoken - https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CentralAuth/+/0d49a86ae7a870a5904a79f64bb32d76dac15ca7/modules/ext.centralauth.ForeignApi.js
Change 623148 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/extensions/GlobalWatchlist@master] Add handling for API failures
Oh, right, I was testing it on Vagrant with no centralauth role, of course it has to use session cookies there.
Change 623148 merged by jenkins-bot:
[mediawiki/extensions/GlobalWatchlist@master] Add handling for API failures when fetching watchlist
@Tgr I believe this is resolved, but since my local set up uses CentralAuth, can you check if it still errors out for you?
I still get the same error. The useful part of the stack trace is
Error: GlobalWatchlistError: en.wiki.local.wmftest.net:8765:API.actuallyGetWatchlist #1 - notloggedin
at GlobalWatchlistDebugger.error
at GlobalWatchlistSiteDisplay.SiteBase.js.GlobalWatchlistSiteBase.errorThe UI does seem to recover from the error now, though.
Okay, that was the goal (the UI recovering recovering, not the still having an error part) - since this should be used with centralauth, notloggedin shouldn't be an issue for the cross site functionality. Is it okay to close this as resolved?
That's your call. It would be nice to handle notloggedin and give the user a login link instead of a cryptic error message, but given the intended audience, might not be worth the effort.
If this gets reported in WMF prod I'll do that (as well as for any other error messages that are found) but until then this isn't a priority, sorry