Page MenuHomePhabricator

File upload token errors
Closed, DeclinedPublic


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

Version: unspecified
Severity: normal



Related Objects

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:04 AM
bzimport set Reference to bz62587.
bzimport added a subscriber: Unknown Object (MLST).

bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Mingle card

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.

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.

Jdlrobson claimed this task.

Upload feature was removed.