Bug: PID in Process View is broken if the /env actuator endpoint is disabled

[cdprete]

Spring Boot Admin Server information

• Version: 3.4.5

• Spring Boot version: 3.4.5

• Configured Security: None

• Webflux or Servlet application: WebFlux

Client information

• Spring Boot versions: 3.4.5

• Used discovery mechanism: Eureka

• Webflux or Servlet application: WebFlux

Description

If the env endpoint is disabled, the PID is shown like in the attached picture below:

Ideally, something like N/A (of course, translated) or - should be used instead.
Moreover, it should fallback to the ProcessInfoContributor information, if it's enabled.
For example:

[SteKoe]

Hi @cdprete,

Ideally, something like N/A (of course, translated) or - should be used instead.

I tend to say that we should filter out null-ish values as they do not carry any useful of information.

It should fallback to the ProcessInfoContributor information, if it's enabled

Sorry to say, but that implies implementing logic dependent on Spring Boot Actuators in the frontend which we try to avoid in terms of maintainability.

[cdprete]

Hi @cdprete,

Ideally, something like N/A (of course, translated) or - should be used instead.

I tend to say that we should filter out null-ish values as they do not carry any useful of information.

It should fallback to the ProcessInfoContributor information, if it's enabled

Sorry to say, but that implies implementing logic dependent on Spring Boot Actuators in the frontend which we try to avoid in terms of maintainability.

Hello @SteKoe.

Sorry to say, but that implies implementing logic dependent on Spring Boot Actuators in the frontend which we try to avoid in terms of maintainability.

It makes sense, but you're contradicting yourself because you already do this with the tags. ;)
There is nothing in the Spring Boot Actuator that says that the values under info.tags (or, even worse, in the Eureka metadata map) have a different meaning than the rest.
As a client of SBA, though, I'm happy to have such a feature in place, so don't take me wrong here (otherwise I would have requested it already :D). But, it's indeed a feature that "customizes" what's returned by the Spring Boot Actuator with some internal logic.

Also, I don't really see it as logic really depending on the Spring Boot Actuator internals. Spring Boot Actuator provides, as of today, the PID information through 2 different channels (at least, by default and standard configuration - aka ignoring custom resources): the env endpoint and the info endpoint.
So, to me at least, sounds just natural that a resilient client needing such information (the UI in this case) may try to use both.

Plus, given that you render both the information in the same view, I assume (but I may be wrong since I never worked with Vue before) that you may already have the information returned by the info endpoint in your view state/store and, therefore, just fall back to the info in there should be pretty easy.

[cdprete]

@SteKoe given that the metadata are already used for the tags, another option would be to propagate the PID in there as well and have the UI checking those entries as well.
Of course, I find this solution not very ideal given that all the required information are available in the payload returned by the info endpoint, but it would be better than nothing.

[SteKoe]

I have had a discussion with my colleagues about your request and they convinced me to implement the fallback as requested. We now join all information we get from different datasources (i.e. env and info actuator) to show even more information about the process (e.g. process owner and parent pid).

[cdprete]

I have had a discussion with my colleagues about your request and they convinced me to implement the fallback as requested. We now join all information we get from different datasources (i.e. env and info actuator) to show even more information about the process (e.g. process owner and parent pid).

Good to hear that.

Given that you're going to display more information, then it's crucial that they're not duplicated, though.
It would be really unpleasant if the same information are then rendered in both the process card and the info card.

In such a scenario, the info card should then not contain the data of the process and have just all of them rendered in the process card instead.