[Wikidata-bugs] [Maniphest] [Commented On] T128486: [Story] Purge Special:EntityData JSON after edit

Addshore added a comment. So from IRC, the % of requests to Special:EntityData that we are talking about here is around 3.7% of requests that currently hit when we might not want them to. F31785447: image.png One option might be to just

[Wikidata-bugs] [Maniphest] [Commented On] T128486: [Story] Purge Special:EntityData JSON after edit

Lydia_Pintscher added a comment. > - Are we talking about both logged in and logged out users? Both. > - Are we talking about requests to Special:EntityData/Q70 for example, or also or only Special:EntityData/Q70.json? The requests I've seen were for .json I believe. It feels

[Wikidata-bugs] [Maniphest] [Commented On] T128486: [Story] Purge Special:EntityData JSON after edit

Addshore added a comment. In order to prepare this for a story time I think we need to get rid of the idea of purging is the solution, and instead start back at the desired behaviour from a user point of view. A BDD or two might help here. Things that need to be considered: - Are

[Wikidata-bugs] [Maniphest] [Commented On] T128486: [Story] Purge Special:EntityData JSON after edit

Ladsgroup added a comment. Two notes: - On Special:EntityData, anything that has argument just passes through Varnish/ATS. So format=foo, revid=666, etc. All see the uncached version - We support too many formats but why not just cache invalidating of ttl of json for now? for

[Wikidata-bugs] [Maniphest] [Commented On] T128486: [Story] Purge Special:EntityData JSON after edit

Addshore added a comment. It would be great to be able to use the cached special entity page when we want the bridge to work at scale to avoid increased network and server load. But for now in an MVP I see no reason that can't use the uncached wbgetentities API? Or alternatively call an

[Wikidata-bugs] [Maniphest] [Commented On] T128486: [Story] Purge Special:EntityData JSON after edit

Lucas_Werkmeister_WMDE added a comment. That’s a possible workaround, of course, but it causes additional network traffic and server load. TASK DETAIL https://phabricator.wikimedia.org/T128486 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To:

[Wikidata-bugs] [Maniphest] [Commented On] T128486: [Story] Purge Special:EntityData JSON after edit

Pablo-WMDE added a comment. Crazy idea suggested by a pragmatic fellow programmer: why don't we simply use our API if we don't want stale information? TASK DETAIL https://phabricator.wikimedia.org/T128486 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] [Commented On] T128486: [Story] Purge Special:EntityData JSON after edit

Smalyshev added a comment. I wonder what to do with other URL forms, like: https://www.wikidata.org/w/index.php?title=Special:EntityData/Q3361378.ttl=dump Is that separate cache entry or the same one? TASK DETAIL https://phabricator.wikimedia.org/T128486 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] [Commented On] T128486: [Story] Purge Special:EntityData JSON after edit

Legoktm added a comment. Yeah...you'd have to purge each variant of ttl and flavor parameter individually, at least right now. TASK DETAIL https://phabricator.wikimedia.org/T128486 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Legoktm Cc: hoo,

[Wikidata-bugs] [Maniphest] [Commented On] T128486: [Story] Purge Special:EntityData JSON after edit

Smalyshev added a comment. Does TitleSquidURLs require full list? Because if have something like: https://www.wikidata.org/wiki/Special:EntityData/Q3361378.ttl?flavor=dump then `ttl` part can be a bunch of formats, and so can be `flavor`. There's

[Wikidata-bugs] [Maniphest] [Commented On] T128486: [Story] Purge Special:EntityData JSON after edit

Legoktm added a comment. Use the `TitleSquidURLs` hook? TASK DETAIL https://phabricator.wikimedia.org/T128486 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Legoktm Cc: Legoktm, mkroetzsch, Smalyshev, Aklapper, StudiesWorld, Lydia_Pintscher,