Page MenuHomePhabricator

Step 1: Show updated information after saving (impact: high)
Closed, ResolvedPublic5 Estimated Story Points


As a user I want to see the updated data inside the article and infobox after changing it in the Wikidata Bridge.

Currently when saving an edit the Bridge just closes and shows the article content again without reloading or similar to show me the newest content after my edit.

GIVEN a Bridge edit
WHEN clicking the publish button

  • start showing loading bar (T237433)
  • API call to save the change
  • On Success, another API call to purge the article with action=purge
    • errors on this API call can be ignored (possibly tracked, but not shown to the user) – worst case, the page will be updated through the usual dispatch process
  • end showing loading bar
  • reload the page (instead of closing the dialog); later (T240333), this will be postponed by a “thank you” dialog


Related Objects

Event Timeline

Restricted Application added a project: Wikidata. · View Herald TranscriptOct 10 2019, 6:54 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Lydia_Pintscher renamed this task from Show updated information after saving to Step 1: Show updated information after saving.Dec 5 2019, 1:14 PM
Lydia_Pintscher triaged this task as High priority.Dec 8 2019, 11:49 AM
Lydia_Pintscher renamed this task from Step 1: Show updated information after saving to Step 1: Show updated information after saving (impact: medium).Dec 8 2019, 1:23 PM
Lydia_Pintscher renamed this task from Step 1: Show updated information after saving (impact: medium) to Step 1: Show updated information after saving (impact: high).Dec 8 2019, 1:27 PM
Lucas_Werkmeister_WMDE updated the task description. (Show Details)
Lucas_Werkmeister_WMDE set the point value for this task to 5.

I just tried it on The page reloads as expected. Unfortunately the old value is still shown. A purge of the article also doesn't help.

Hm, I just tried it out and it works for me :/ (it’s a bit annoying to retry due to T128486.)

So the problem seems to be logged-in (@Lucas_Werkmeister_WMDE) vs anonymous user (@Lydia_Pintscher, myself).
Logged-in users hit the application server while anonymous are presented with a higher level [HTML] cache result (x-cache-status: hit-remote). There should (TM) be solutions in place overcoming this challenge but something is possibly broken on (en)beta.
Way to show that the parser cache contains the updated value: (random query is used to not hit the high level cache).

@Lucas_Werkmeister_WMDE found out that (de)beta does not seem to have the quirk.

Lucas_Werkmeister_WMDE closed this task as Resolved.Mar 10 2020, 11:16 AM
Lucas_Werkmeister_WMDE moved this task from Doing to Done on the Wikidata-Bridge-Sprint-15 board.

This might be due to the general brokenness of the beta cluster at the moment (I think T247078 is the general for that). It’s notable that Lydia and Pablo were both logged out when they tried this, whereas in my successful attempt I was logged in; it looks like purges aren’t reaching anonymous users correctly. Lydia was able to verify this task (i. e., updated data was correctly shown after saving) on de beta wikipedia, though, which seems to be less broken, so we agreed this can be closed, as the problems are likely not Bridge’s fault.