Hi @Thnidu, thanks for taking the time to report this!
What is "the mobile in WP Beta"? Is this about some Wikipedia website (which one, links welcome)? Is this about the Wikipedia mobile application?
Steps to reproduce are welcome. :)

1. It's on the Google Play Store as Wikipedia Beta https://play.google.com/store/apps/details?id=org.wikipedia.beta. You may need an Android phone (see bug report) to get the right one and replicate this test.
   1. Install it.
   2. Open it.
   3. In the app, go to https://en.m.wikipedia.org/wiki/User:Thnidu/sandbox#T173098_test . You'll see the successful edits I just made there. (I kept reiterating to check the details of each step.) As I type this reply in gmail on my laptop, I see it here but not on my mobile. Of course this should replicate on any page, but this seems to be the right place!
   4. Make an edit of your own.
   5. Hit *Next*. You will see the effect of the edit that you just made.
   6. Optionally, choose an edit summary box.
   7. Hit *Publish.* On the Android the section will look unchanged.
   8. Open it in your browser of choice. (I use Firefox. Same result in Chrome.) You'll see the effect of the edit.
   9. Open the page on a... stable? (What do we generically call a device that's *not* mobile?) You will see the change in effect.
   10. Back to the Android. Click the tab-history icon: the "page" icon in the header bar with a number in it, up to "9+"; it's 2nd from the right, next to the vertical-three-dots menu. You'll see the tab history laid out vertically. The bottom tab will be the most recent one; close it by clicking the X.
   11. Reopen the page. *Now* you will see the edit in effect.

HTH!

. http://www.gnuterrypratchett.com/

This is a known issue. (Previously: T141763, T137902, T137669)

The Android app obtains cached article content from RESTBase. When an article is edited (an action performed via the MediaWiki-Action-API, not RESTBase), a ChangeProp event is queued to inform RESTBase to regenerate and cache a new copy of that article for the app endpoints. This notification happens asynchronously. When the app reloads the article, ideally RESTBase has been updated, but it sometimes happens that it hasn't been.

We've been getting by with a short delay in the app before reloading, but lately I, too, have seen the old version reload after editing. We need a better fix but I don't believe there's any consensus at this point on what that should be. I couldn't find an existing task about this, so let's leave this task open for further discussion.

In the meantime, in the event this occurs, you can refresh the article by pulling down with your finger, and you will usually see the updated version on the first or second try.

Yes, to refresh a page in the Android app you pull down from the top of the screen until the refresh indicator appears, then let go.

One thing to try is to retrieve the revision number from the edit response, and use that when loading the just edited page.
.../page/mobile-sections-lead/{title}/{revision}
+ .../page/mobile-sections-remaining/{title}/{revision}

As we work toward enabling visual editing in the apps, perhaps we could keep in mind the idea of POSTing directly to RESTBase via /page/html/{title} or /page/wikitext/{title}, which would solve this once and for all.

This issue concerns the service(s) that propagate resource change events and issue update requests resulting from such changes to the Page Content Service. Those are maintained by the Core Platform Team, so I'm tagging them here.

That said, this task should probably either have some concrete acceptance criteria or be closed as non-actionable. As I understood it the last time this was discussed, we'll never be able to fully eliminate the possibility of delay between an edit and a PCS update rendering request, but under normal circumstances the turnaround should be fast enough not to be noticed by the user. Have reports of delays increased recently?

As reported by me in https://phabricator.wikimedia.org/T237859 , the update of the wikidata content of the dewiki "Briar (Instant Messenger)" page recetnly had a delay of more than 8 days which is not acceptable.

Knut (Notknut) of Wikidata team has been contacted, he recommended to fiel the issue regarding wikidata (https://phabricator.wikimedia.org/T237859).

Remark: the update of the dewiki page wiki body content took a very few minutes.