Last modified: 2014-09-19 18:43:50 UTC
In a 30 day period the following errors were thrown by users trying to upload images. Ideally, when doing an upload we should check login status before attempting the upload as it's possible they left a browser window open and their login inspired. If they are not logged in or can't get a token, let's prompt them to login again. Invalid token 3468 Bad token name. 1983 Anonymous token. 1574 badtoken 195 Failed to retrieve token. 172 upload/error/badtoken 52 edit/error/badtoken 4
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1766
For some context, can you also provide number of successful uploads in that same 30 day period?
Also the numbers are wrong. Bad token name. 192 badtoken 195 edit/error/badtoken 4 Failed to retrieve token. 77 Invalid token 8 upload/error/badtoken 54 In same period we had 3821 successful uploads.
So 530 token errors in 3821 uploads.
The chunked/stashed upload api does some very sketchy things with session data. If things are going awry on the backend, it could present as a "bad token" (e.g. the upload stuff killing the current session somehow). Just mentioning because I'm reminded of (non-wmf) users with suhosin which changed some assumptions about session handling, and caused chunked upload not to work with the symptom of having a lot of "bad token" failures. Of course in that case it was for every upload.
Update: upload/error/badtoken 120 edit/error/badtoken 4 select event_errorText, count(*) from MobileWebUploads_7967082 where event_action = 'error' and timestamp > 20140401000000 group by event_errorText 1551 successful uploads in same period.