New posts/replies do not appear in real-time; manual refresh required

Contribute Bug
1

Summary

In our Discourse instance, new posts and replies in topics are not appearing automatically. Users must manually refresh the page to see later posts, despite being actively viewing the topic.

This appears to be a regression in real-time updates (MessageBus/WebSocket/polling), as no themes, plugins, or custom components are installed.

Environment
• Discourse version: 2026.4.0-latest (9776b417b8)
• Hosting: self-hosted
• Custom theme: default

Steps to Reproduce

1.	Open a topic in one browser/session
2.	Open the same topic in another session/user account
3.	Post a new reply in the topic
4.	Observe the original session

Expected Behavior

New posts should appear in real-time without requiring a manual page refresh (via MessageBus updates / live topic updates).

Actual Behavior

New posts do not appear in the open topic view.
They only appear after:
• Manual browser refresh (F5 / reload), or
• Navigating away and back to the topic

Notes / Observations

•	No custom plugins or themes that could interfere
•	Appears consistent across users/sessions
•	Issue affects visibility of later posts in a topic thread specifically
•	Suggests possible regression or failure in:
•	`MessageBus` subscription handling
•	`/message-bus/ long polling / websocket` fallback
•	topic update stream (`topic:reload`, `post:created`) propagation

Impact

•	Breaks real-time discussion flow
•	Causes users to miss new replies unless they refresh
•	Creates confusion about whether posting succeeded or not

Request

Could you please confirm whether there is a known regression affecting real-time topic updates in recent builds, or advise on what subsystem to inspect (MessageBus, polling fallback, etc.)?

Moving a post between topics does not load the post on existing clients
2

Are you behind a proxy such as cloudflare etc?

3

No - there is no proxy or CDN in front of the instance (no Cloudflare or similar).

This is a direct self-hosted setup with standard networking, so nothing external should be interfering with MessageBus/WebSocket or long-polling behaviour.

Given that, it seems less likely to be caused by intermediary caching or connection buffering, and more likely something internal to the real-time update mechanism itself (e.g. MessageBus subscription, polling fallback, or client-side handling in this build).

Happy to provide any logs (e.g. /logs , browser console, or /message-bus/ requests) if that would help narrow it down.