Hi @MSantos , @Tsevener !

I've tried to reproduce the issue and have some questions/info to share about

Steps to reproduce:

I edited a short description in revision 1014871649
I edited article text in revision 1014869317

Actual results:

I faced with a few issues during this steps:

1. When I edited short description or article text via mobile app (Android), I found, that the changes did not apply immediately - I refreshed application to get them. However, if we check this invision mockups (link), it seems there is no need to refresh the page for steps 5-7

2. Since the short description is unavailable for mobile and desktop versions (this is the feature only for mobileapps), I've tried to check the diffs for article text first.

I used ID to check the previous version of an article:

Newer version
https://en.wikipedia.org/w/index.php?title=Blaster_Master_(video_game)&oldid=1014869317
Older version
https://en.wikipedia.org/w/index.php?title=Blaster_Master_(video_game)&oldid=1014867271

Compare changes between two of them:
https://en.wikipedia.org/w/index.php?title=Blaster_Master_%28video_game%29&type=revision&diff=1014869317&oldid=1014867271

I've attempted to do the same for mobileapps:
https://en.wikipedia.org/api/rest_v1/page/mobile-html/Blaster_Master_(video_game)/1014869317 --> (released by Sunsoft for the Nintendo Entertainment System)
https://en.wikipedia.org/api/rest_v1/page/mobile-html/Blaster_Master_(video_game)/1014867271 --> (released by Sunsoft for the Nintendo Entertainment System (NES))

I can see a different text between that two version

Now, try to check article short description diffs
https://en.wikipedia.org/w/index.php?title=Blaster_Master_%28video_game%29&type=revision&diff=1014871649&oldid=1014869317

And check them for each ID:

Newer version
https://en.wikipedia.org/api/rest_v1/page/mobile-html/Blaster_Master_(video_game)/1014871649 --> (Video game for Nintendo Entertainment System)
Older version
https://en.wikipedia.org/api/rest_v1/page/mobile-html/Blaster_Master_(video_game)/1014869317 --> (Video game for Nintendo Entertainment System) but should be (Video game for NES) instead
So it seems, for mobileapps article, ID does not reflect the actual short description.

Regarding this, I want to clarify what exactly should be fixed. List of issues that I've found:

1. Mobileapp needs to be refreshed to show actual edited results when using a smartphone.
2. Any ID endpoint in mobileapp shows only the last version of the short description.

So my questions are:

• Does my research correlate with the task description? Are the issues from my research relevant?
• Should I pay attention to the RESTbase to solve this issue?

Note: I've found that edit history is not implemented in the mobile app, it prompts me to the mobile version of Wikipedia instead. I suppose a feature of direct check of editing history will be added to the mobile app later.

From restbase, we can see that the endpoint with revid parameter does not apply the same router filtering as the base endpoint.

@Pchelolo does that mean that no cache is applied to endpoints with revision ID or there is a default cache rule that could prevent the page to be updated right after an edit?

@vadim-kovalenko thanks for the investigation! I think it's possible the first issue you listed lines up with this task description. When I tried updating with iOS (on our in-development builds, not in the App Store yet) I was seeing it not reflect the edited results, even though I know we are attempting to refresh and fetch that particular revision number after an edit successfully goes through. It did seem to correct itself after repeating the same mobile-html call (with the specific revisionID) a few seconds later, so it seems like some sort of caching delay on the server. It could be that the Android app is acting the same way. Interestingly I didn't detect any delay when editing in a different area of the article.

Your 2nd issue is new to me and I think also worth fixing. A mobile-html endpoint supplied with a specific revision ID should reflect the short description template value as it was in that revision, even if it's not the latest.

I'm unsure if this is still happening, but going to reduce the priority down on it since we haven't had complaints. It looks like at the time we were able to bypass the refresh delay locally for short description template changes (see PR comment and commit).

This is a regression test case worth keeping in mind as we sunset restbase. We'll need to confirm users will see their reflected changes in mobile-html after changes in section text, short description template in EN, as well as Wikidata article description changes in non-EN. I now see 3 different ways we're currently refreshing after an edit in the iOS app:

1. If it's a change to the short description template through our native article description editor screen, we just inject it locally to the in-app web view (due to this bug, refreshing mobile-html with a new revisionID didn't always reflect the short description changes).
2. If it's a change to the Wikidata article description via our native article description editor screen (i.e. Non-EN), we poll mobile-html for a change in the E-Tag (see source).
3. If it's a change to general article wikitext through our section editor, we take the new revision ID after successful POST and pass it into the next mobile-html refresh call to get the reflected changes.