daniel added a comment.

I think just switching to LATEST_FROM_SLAVE is not an option - we introduced LATEST_FROM_SLAVE_WITH_FALLBACK for a specific need that was not addressed by LATEST_FROM_SLAVE. If I remember correctly, the scenario was: after an item was created with a sitelink, the client is notified of this, and the linked page gets purged. However, if the notification is too quick, the new item isn't found on the slave database, so no language link is shown. This is especially annoying when the item is created via the client side widget: the user will use the "add link" dialog, and then not see the link until the page gets purged manually. The problem was that the code for fetching entities (or sitelinks) doesn't know about the "urgency" to find the item, nor does it know whether it's called from a POST request or not.

I see two options: introduce getEntityRevisionForUpdate or getEntityRevisionTryHarder or something. Or, make LATEST_FROM_SLAVE_WITH_FALLBACK only actually fall back to master if called from a POST request (or CLI).


TASK DETAIL
https://phabricator.wikimedia.org/T154555

EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: PokestarFan, aude, Ladsgroup, Lydia_Pintscher, Amire80, daniel, Johan, Glaisher, Nemo_bis, Gilles, PleaseStand, Krenair, Joe, aaron, gerritbot, MZMcBride, Aklapper, Catrope, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, Izno, Wikidata-bugs, Mbch331, Jay8g
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to