fix(#5450): Trigger status update events not only when the status itself changes but also when the details change so that the UI displays the correct, most recent, information

[cdprete]

Fixes #5450.

I can revert the part about the echo health indicator, if wanted.

[cdprete]

I can't understand why that test is now failing after the change 6b3eaad.
Some guidance would be helpful, because I'm kind of failing to understand what the setup and expectations of that test are.

[cdprete]

I can't understand why that test is now failing after the change 6b3eaad. Some guidance would be helpful, because I'm kind of failing to understand what the setup and expectations of that test are.

Ok, I sorted this out.

The instances in the test were defining as healthUrl a path which was not existing.
As a result, the call to /application/health triggered by the StatusUpdater was returning a response like { path=/application/health, error=Not Found, requestId=eda53c52-8, status=404, timestamp=2026-06-17T17:52:06.979Z } and, given that the requestId and timestamp are changing for each request, this was triggering an additional STATUS_UPDATED event (which is indeed correct because the details have changed from one call to the next one).

To fix this without changing the test, I added --management.endpoints.web.base-path=/application so that /application/health can indeed be found instead of resolving in a 404 with these changed details all the time.

[cdprete]

Hi guys.

I was wondering, who is actually updating the information in red below?

In the code I can see that instance.statusTimestamp is used in InstancesList.vue, but I see no SSE consumption.
Am I right or will now this change impact, in the wrong way, the time shown there because multiple STATUS_UPDATED events are received, each with their own timestamp (even if the state inside is still, from one poll to the next one, UP for example)?

[cdprete]

Hi guys.

I was wondering, who is actually updating the information in red below?

In the code I can see that instance.statusTimestamp is used in InstancesList.vue, but I see no SSE consumption. Am I right or will now this change impact, in the wrong way, the time shown there because multiple STATUS_UPDATED events are received, each with their own timestamp (even if the state inside is still, from one poll to the next one, UP for example)?

Hi again.

I checked the code more carefully and, if I'm not wrong, we indeed use SSE for that view which is done in the applicationStore and calls de.codecentric.boot.admin.server.web.ApplicationsController#applicationsStream from the backend. Please correct me if I'm wrong.

If I'm right, de.codecentric.boot.admin.server.services.ApplicationRegistry#getStatus needs to be adjusted according to the new fact that multiple STATUS_UPDATED events can come now.
Therefore, I'm putting this in draft for now.

[cdprete]

Hi guys.
I was wondering, who is actually updating the information in red below?
In the code I can see that instance.statusTimestamp is used in InstancesList.vue, but I see no SSE consumption. Am I right or will now this change impact, in the wrong way, the time shown there because multiple STATUS_UPDATED events are received, each with their own timestamp (even if the state inside is still, from one poll to the next one, UP for example)?

Hi again.

I checked the code more carefully and, if I'm not wrong, we indeed use SSE for that view which is done in the applicationStore and calls de.codecentric.boot.admin.server.web.ApplicationsController#applicationsStream from the backend. Please correct me if I'm wrong.

If I'm right, de.codecentric.boot.admin.server.services.ApplicationRegistry#getStatus needs to be adjusted according to the new fact that multiple STATUS_UPDATED events can come now. Therefore, I'm putting this in draft for now.

Fixed with 0418ccf

[cdprete]

I think it's now ready for review, unless there is some other place in the codebase which I should adapt and I'm not aware of it.