Page MenuHomePhabricator

Hybrid testing should use the JS mock API on the PHP side, for files at least
Closed, ResolvedPublic


From the discussion in

Testing is hampered by the ApiHelper calling the production api rather than the mock, so we're getting different file information.
Fixing that probably belongs in a dep or follow up anyways.

This testing bit is related to .. so, whatever solution it is should handle it all together.

For testing template handler code there, I pass offline mode over to the PHP scripts. Otherwise, I have the same problem of getting information from the live API, not the mock API.

Event Timeline

Arlolra created this task.Jun 6 2019, 5:04 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 6 2019, 5:04 PM
ssastry triaged this task as Normal priority.Jun 11 2019, 2:35 PM
ssastry moved this task from Backlog to Deployment on the Parsoid-PHP board.
ssastry assigned this task to Arlolra.Jun 11 2019, 6:36 PM

Change 516549 had a related patch set uploaded (by Arlolra; owner: Arlolra):
[mediawiki/services/parsoid@master] [WIP] Use JS mock API when hybrid testing

Change 516549 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Use JS mock API when hybrid testing

The JS mock API and the ApiHelper.php don't exactly play nice together, in that they have different ideas of which formatversion to use. There's also some redundancy with the JS baseconfigs and the ApiHelper.php cached data.

Arlolra added a subscriber: cscott.Jun 12 2019, 4:15 PM

As @cscott says,

09:57 <+cscott> anomie, subbu: assuming you're talking about the JS mock API? yes, that's the
main problem with it: it doesn't implement the way the siteinfo varies when you
reset the language code.
09:57 <+cscott> that's why my Api/Env cached direct access to mediawiki API, for non-file stuff
that's a better proxy.
09:58 <+cscott> but we do have siteinfo.json cached for all the different languages, what we
don't have is a way to communicate the desired language to the mock API
09:58 <+cscott> theoretically we'd set up a different mock server for each language used, and
then pick the proper URL based on the language, which is the way we do it for
09:59 <+cscott> PHP's internal parsertests implementation does it differently: it has special
internal access to $wgLanguageCode
10:00 <+cscott> possibly we need to set up a similar 'backchannel' to the mock API, but it's
not exactly clear how best to do that.
10:01 <+cscott> possibly encoding it somehow in the URL path is easiest, like
10:45 <+cscott> because JS doesn't use the mock API except for file requests
10:46 <+cscott> it uses the cached siteinfo.json for the environment (instead of doing API
requests, either to mock API or otherwise)
10:47 <+cscott> and we use our own 'backchannel' to communicate the language setting when we
set up the Env, which makes sure we use the right siteinfo.json
10:47 <+cscott> and we have a horrible hack in mockapi to handle localization of the "File:"
prefix, since we don't actually 'known' the correct language for the request,
so we basically answer requests for any known 'File' translation (IIRC)
10:48 <+cscott> either that or we hard code the various possible File translations into the path
10:48 <+cscott> anyway, the "same as JS" approach would be to continue to use the Api\Env for
siteinfo, and just use the mock API for file-related requests.
10:49 <+cscott> but if we wanted to do things "properly" we need to communicate the proper
language and other parsertests options settings to the mock api, possibly by
just URL encoding them into the path or as a hidden extra query parameter.

Change 517691 had a related patch set uploaded (by Arlolra; owner: Arlolra):
[mediawiki/services/parsoid@master] Pass the wiki prefix to the mock api via a backchannel in the path

Change 517691 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Pass the wiki prefix to the mock api via a backchannel in the path

Arlolra closed this task as Resolved.Jun 18 2019, 6:10 PM