Page MenuHomePhabricator

action=mobileview shouldn't return sections when the range of sections asked for is out of range
Closed, ResolvedPublic

Description

https://en.wikipedia.org/w/api.php?action=mobileview&format=json&page=10_dollar_note&sections=2-&prop=text should return zero sections, since I am asking for sections '2-' and there is only a section 0 on that page. Instead I get all sections + 2 empty sections


Version: unspecified
Severity: enhancement

Details

Reference
bz61868

Event Timeline

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

bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1727

It seems like this should throw an error saying invalid arguments (sections should either be a number of the keyword all)

I'd say this is super super low priority - a good patch for a new developer to MobileFrontend to take care of?

It actually affects the app - since we don't know clientside how many sections there are, I can't just not send the second request. So this should either send an error message or no sections, rather than false data.

It seems we are saying the same thing? I'm suggesting error message. Why are you not using sections=all any reason?

Not using section=all because reduces data transfer? And it's not super duper low priority since all pages with only one section produce errenous data and the app displays those as it is supposed to (see attachment). Hence this is something I'd like Max (or myself? :P) to fix ASAP, not 'super low priority bug for volunteer months from now'

(OT: Would an 'API' component make sense for MF?)

Created attachment 14906
Effects of this bug on the Android app

Attached:

(In reply to Jon from comment #2)

It seems like this should throw an error saying invalid arguments (sections
should either be a number of the keyword all)

action=mobileview has been accepting ranges for a few months now in sections= :)

Data transfer vs number of http requests. With Gzip encoding is amount of dat really an issue? Have you benchmarked this?

If this is accepting ranges it is not well documented. The documentation says this which is not clear at all how this is expected to work - is this all except the last section or something else?:

Ranges without second number, e.g. '1-' means get all until the end.

Change 121410 had a related patch set uploaded by MaxSem:
mobileview: handle requested sections outside of range

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

Change 121410 merged by jenkins-bot:
mobileview: handle requested sections outside of range

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