Related to T282926, but not currently seen as a requirement for its completion.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T338522 Implement agreed post-launch security and control measures in the Wikifunctions system | |||
| Resolved | Jdforrester-WMF | T282917 Cache requested resources locally in the orchestrator with an appropriate TTL | |||
| Resolved | Jdforrester-WMF | T306446 Develop a plan for how we're going to cache things inside the orchestrator |
Event Timeline
Comment Actions
Now that we have landed rMSFO3c9b53082ef7: Add map of previously dereferenced ZIDs to the ReferenceResolver. (which implements a non-persistent cache within the process only), I think this (setting up a more persistent caching service) can count as no longer needed for Zeta and can move to Theta.
Comment Actions
Note for self/others for later implementation: curl -sSI https://www.wikidata.org/wiki/Special:EntityData/Q2.json etc. will get you the headers and so allow for a rapid check against mw-api-int-ro for cache expiry.
Comment Actions
@Jdforrester-WMF Is this something that we already addressed with the caching work that we did in T390549: Implement Object and Wikidata entity caching mechanisms in the function-orchestrator to drive up user experienced performance when making function calls?
Comment Actions
Not really, this is mostly around the Wikidata side of that work (which we have not done yet). Once T397409: If we provide caching of retrieved Wikidata entities, we will reduce by at least 50% the average runtime of Wikidata content-based functions, reducing timeouts and user frustration. is done, this can probably be Resolved.