Sun, Jun 23
@cooltey Updated on app-editor-tasks. Please try now and see if the result matches your expectations.
Sat, Jun 22
Not high priority since the Android app can just ignore the info that isn't properly updated and re-query the MW API in the meantime.
Determined that extmetadata should be dropped for this reason, but querying CirrusSearch will always incur a ~1.5-2 second penalty.
Fri, Jun 21
I think the batching introduced here is indeed causing 429s in CI: T226264: Recommendation-API CI testing is flaky due to frequent 429s from Wikidata Query Service
Hmm, now that I'm digging, I see that the batching was just introduced: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/recommendation-api/+/9603d4282492103eecc0b1646ea2911138c848af%5E%21/lib/article.creation.translation.js
Sure. The specific URL that the flaky test is hitting is https://de.wikipedia.org/api/rest_v1/data/recommendation/article/creation/translation/en.
RESTBase PR: https://github.com/wikimedia/restbase/pull/1154
Blocking this on confirmation that it will be used. T225443#5274233
@Dbrant can you confirm whether you actually plan to use the new media-list endpoint before I submit a RESTBase PR to publicly launch it?
RESTBase PR: https://github.com/wikimedia/restbase/pull/1153
Thu, Jun 20
Wed, Jun 19
Local ab numbers when fetching page HTML over HTTP from the public RESTBase endpoint:
Tue, Jun 18
I'm out next week, so someone will have to pick this up in my stead.
Ah -- there's a bot for this. Are the GitHub alerts more or less safe to ignore, then?
I'm on offsite next week and this isn't happening before then.
Mon, Jun 17
Since there's zero chance of resolving the ChangeProp dependency tracking / invalidation piece of this before the target launch date for in-app caption suggestions, I think we should proceed as discussed in the Audiences-Platform sync last week, namely, by creating a new /page/media-list endpoint that simply returns the File page titles (and perhaps other on-page info) for the non-UI files in the page, without including other info gatherred from the MW API; and the app should then gather any additional needed info directly from imageinfo and getentities. (There's ongoing discussion on T224920 about the proposed REST API wrapper for imageinfo and possibly wbgetentities.)
Sorry, discussions around this ticket have sort of evolved in focus, but the description hasn't been updated to reflect that. As the description indicates, it started life as a possibly nice-to-have REST endpoint to work around the apparent slowness of the imageinfo API, but currently we're mostly thinking about whether it would help solve T225443: Media endpoint does not refresh structured captions. The PCS /page/media endpoint, as currently written, includes data from imageinfo and SDC on every (non-UI) image used in the requested page title, and so the content cached in Varnish for that title must be purged via ChangeProp anytime any of those images' File page contents or SDC content changes; and that currently isn't happening (see T225443#5248591 for @Pchelolo's comment on that—we have scalability concerns). /page/media also happens to be quite slow (I think because of its heavy imageinfo usage).
Fri, Jun 14
The existing endpoints that return extended metadata (/page/media, /media/image/featured) are choosy about what fields they request from the MW API and return. Do we want to pick and choose likely candidates of interest here as well, or just return everything? I'm leaning slightly toward the latter.