I have run into an intermittent issue where an edited post is successfully saved, but the already-rendered post in DiscourseHub on iOS sometimes remains stale until I refresh the topic.
Environment
The production site is my own self-hosted Discourse installation, which I use privately as a personal study archive.
At the time I reproduced this today:
- Client: DiscourseHub on iPhone
- iOS: 27.0.1
- Production Discourse:
v2026.10.0-latest +112 - Site: self-hosted, private study archive
- Default iOS browser: iCab Mobile
I changed my default browser to iCab Mobile because of an unrelated local downloads issue. However, this reproduction occurred while I was using the Discourse site inside DiscourseHub, rather than after opening an external browser, so I don’t currently think the choice of default browser is relevant.
Real-world workflow
The topic where I noticed this contained roughly 50 posts representing lecture slides.
My normal workflow is:
- create a post containing an image of a lecture slide;
- later work through the topic consecutively;
- edit each existing post;
- add an OCR transcript / notes underneath the already-posted slide image;
- press Save Edit and continue to the next slide.
So these are not synthetic rapid edits: this is a normal study workflow where I am progressively adding OCR transcripts to lecture-slide image posts.
For the earlier posts in the topic, pressing Save Edit immediately replaced the displayed post with the newly edited content, as expected.
Later in the same topic I encountered cases where:
- I edited the post and added the OCR text.
- Pressed Save Edit.
- The edit was successfully saved.
- The post displayed in DiscourseHub remained on its previous content.
- Refreshing the page immediately showed the already-saved edit.
So the edit itself appears to have succeeded. The stale part seems to be the already-loaded client representation of the post.
Development test
I then created a completely clean development instance from current upstream main:
833e1576d47 DEV: Update README.md note on self-hosting (#44320)
I generated a topic containing 60 posts, with an image in every post, to mimic
the structure of the production topic.
I then repeated the workflow in Firefox on Linux, editing text into the existing image posts.
I initially saw one possible stale update around post 19 in my first test.
However, after repeating the experiment more carefully - including creating a fresh 60-post topic and editing posts consecutively - I have not been able to reproduce the production behaviour in Firefox/Linux on current main.
Edits there have been repainting the post immediately after Save Edit, including well beyond the first group of posts in the topic.
This has made me less confident that topic pagination or the normal 20-post stream chunk is itself the cause.
Next test
The production reproduction was in DiscourseHub on iOS, rather than a Home Screen PWA.
My next intended comparison is therefore:
- current upstream Discourse development instance;
- the same 60-post image topic;
- the same iPhone running iOS 27.0.1;
- DiscourseHub first;
- Safari on the same iPhone as a control;
- optionally the Home Screen web app as another comparison;
- edit the posts consecutively using the same OCR-style workflow.
At the moment my development laptop is on eduroam, so directly exposing its local development server to the iPhone is not straightforward.
Is running the current-main development instance on the same iPhone in DiscourseHub the right next step for narrowing this down?
If so, is there a preferred way the Discourse team uses to expose a local development instance to an iPhone / DiscourseHub for testing, ideally over HTTPS?
On the next occurrence I can also leave the stale post unrefreshed and capture a screen recording, so that the successful save/server state can be compared directly with what the already-open DiscourseHub client is displaying.
Possibly relevant observation
This behaviour feels similar at a high level to the stale-client-state issue I ran into while working on PR #43285, “Refresh event dates in topic lists”.
That was a different code path, and I am not suggesting it is the same bug.
However, the observable failure was similar: the server-side state could be correct while an already-loaded client continued displaying stale state until the relevant refresh/re-hydration happened.
With the event-date issue I was able to observe an A/B situation on different already-open clients depending on timing.
That makes me wonder whether this edit issue is also somewhere in the notification / model-update / render chain rather than the edit itself failing.