Bug: Entire UI still refreshes every X seconds

[cdprete]

Hi guys.

In version 4.1.1 I can still see the UI refreshing entirely every X seconds.
I had the impression that this was fixed with SSE, but it doesn't seem to be the case.
What's worse is that, on every refresh, since the entire UI refreshes, the metrics are lost and they start again from the beginning:

Recording.2026-06-24.143410.mp4

I'm clueless about what the issue could be this time.

[cdprete]

The issue seems indeed to be caused by SSE.
Every time a new event arrives, everything resets.

[andreasfritz]

I can reproduce that. We should fix it.

[cdprete]

I can reproduce that. We should fix it.

The issue is in the health details component that blindly resets everything on every SSE event that gets received.
I assume that the assumption in that implementation was that an event will be received only on status changes and, if I'm right, this is a regression bug caused precisely by version 4.1.1.
I was not aware of this specific piece of logic in the UI, so my bad for this (even though I asked in #5457 (comment) if there were other potentials places to check ;)).

We should ideally change that to make it compare the status of the 2 instances (the existing one and the received one through SSE) and only trigger the reset + reload if they're different.

I could open a PR for it, but I need first @SteKoe to explain me what's the idea behind the metricKey counter that's used in there.
Is it to avoid concurrent executions of the method? If it's so, can this really happen - and if it's so, how - given that JS is single-threaded?

[SteKoe]

In my view, the problem runs deeper. Currently, whenever the status of an instance changes (including changes to the instance’s details), we log the InstanceStatusChangedEvent as an event to the stream, which causes all pages in the frontend to be re-rendered (as the object reference to the instance is updated).

I would like to eliminate this mechanism, as I believe that an update to status information should not necessarily result in all pages being re-rendered. To still maintain a reactive front-end, we should consider, on the back-end, whether to introduce more granular events: for example, an InstanceStatusChangedEvent, which would only track the parent status of an instance (i.e. UP, DOWN, UNKNOWN) and an InstanceStatusDetailsChangedEvent, which takes the components into account. One of the problems is that, for instance, whenever the free disk space changes, an InstanceStatusChangedEvent is currently always triggered.

I’ll discuss this with my colleagues. What do you think?

[cdprete]

Hi @SteKoe.

Indeed, the way things are handled as of today it's not ideal.

This is true not only for this specific case but it's a more general issue. For example, metrics suffer of the opposite problem, in the sense they're not reactive at all. In fact, there is #5287 in the "backlog" for this.

Ideally, each event type should be responsible of its own part of the UI (e.g.: info updates should update only the info section, status updates should update only the health section and so on) and an application instance should not be driven by its events.
That's probably the currently main design flaw in the sense that even a tiny change to some details of an instance are handled like the whole thing changed (as you also said).
Then, to have separate events or not, I think it's a minor thing.
Of course, separate events would then open the door to multiple events in a given instant if, for example, both the status changed and the details in the health.

The real point is that the UI, as a consumer of those events, must know how to properly handle them.
Just refresh everything because something changed is not the solution.

One of the problems is that, for instance, whenever the free disk space changes, an InstanceStatusChangedEvent is currently always triggered.

Which, from a monitoring point of view (which is the whole point of SBA), it's correct.

The current behaviour is not any different from what it was available in version 4.0.x.
The only difference is the source of the data:

• in 4.0.x the health was being called directly, causing the N (UI instances open) calls issue
• in 4.1.1 the data are coming through SSE

and the fact that, with SSE, the events are stored in memory which is also arguable.
For example, why do we have to store all (until compaction) the INFO_UPDATED events?
They're purely used for rendering purposes; they don't participate into notifications/alerting or anything else.

The same can be said for STATUS_UPDATED events. Ideally, only the last one (by status value) is needed.
If a full journal is needed, this should be offloaded to an external datasource (database, file, Hazelcast... you name it).

Of course, if SBA would be scalable, in the sense that the monitoring is distributed across the available instances, all this would be less of an issue but still, anyway, somehow, relevant.

[hiSandog]

Since the reset is now narrowed to health details reacting to every SSE event, a regression test could be framed around an event that does not change the selected instance/status. The UI should preserve the metric series and expanded/detail state when the incoming event is equivalent for that view. That would catch both the original full refresh behavior and future regressions where SSE is treated as a blanket invalidation signal.