CAMEL-24592: only expose health check stack traces in full exposure level

[Croway]

What

CamelHealthHelper.applyHealthDetail added the full stack trace of a failed health check as
error.stacktrace to the per-check data at every exposure level except oneline. With the default
camel.health.exposure-level=default, any DOWN check whose result carries an exception — a consumer that
lost its broker, a pool that cannot connect — serialised the whole cause chain into /actuator/health.

error.stacktrace is now emitted only when the exposure level is full.

Why

• error.message is still reported at the default level, which is what Spring Boot's own health
  indicators expose (class and message, never a trace).
• camel-main's ManagementHttpServer is stricter still: it includes error-stacktrace only when the
  caller asks for it with ?stackTrace=true.
• It matches the documented meaning of the levels: full is described as including all details from all
  the invoked health checks, and the stack trace is the most verbose detail there is.

camel-microprofile-health (and therefore Camel Quarkus, which builds its health responses through that
module) currently emits error.stacktrace at the default level as well; that is the behaviour CAMEL-18832
aligned this module to. The same gating is applied there in apache/camel#26046 so the two
runtimes stay aligned, and this PR should merge together with, or after, that change.

The trace is unchanged in the application log; no logging was added or removed.

Behaviour change and how to opt back in

At camel.health.exposure-level=default (the default) the actuator response no longer contains
<check-id>.data.error.stacktrace. error.message is unchanged. To get the trace back:

camel.health.exposure-level = full

Note that full also stops filtering health check metadata out of the per-check data, so it is more
verbose than the previous default in other respects too. An upgrade guide entry for this will be proposed
separately against apache/camel.

The diff is deliberately confined to the stack-trace gating, since CAMEL-24512 changes the same method
(error.message overwritten when several checks are DOWN) under a different assignee.

Tests

New CamelHealthHelperTest builds a DOWN result carrying an exception plus a detail and asserts:

• default — error.message present, error.stacktrace absent from the check data;
• full — both present, the trace containing the exception message and frames;
• oneline — no details at all.

mvn test -pl core/camel-spring-boot -Dtest='CamelHealthHelperTest,CamelHealthTest,CamelProbesTest' →
Tests run: 5, Failures: 0, Errors: 0.

core/camel-spring-boot/src/main/docs/spring-boot.json was regenerated for the clarified
camel.health.exposure-level description.

Claude Code (Opus 5) on behalf of Federico Mariani

[oscerd]

Hi @Croway — I looked at this because I had implemented the same change a week ago (as part of CAMEL-24499) and then reverted it in review. Most of your rationale holds up, but one load-bearing part of it does not, and I think it's worth settling before this merges.

The camel-main point is correct. ManagementHttpServer does gate it: ctx.request().getParam("stackTrace") at line 641, error-stacktrace emitted at line 976. Opt-in there, as you say.

The microprofile point is not. On current camel main, CamelMicroProfileHealthHelper.applyHealthDetail is structurally identical to what CamelHealthHelper looks like before this PR:

result.getError().ifPresent(error -> {
    builder.withData("error.message", error.getMessage());
    final String s = ExceptionHelper.stackTraceToString(error);
    builder.withData("error.stacktrace", s);
});

The error block sits outside the exposureLevel.equals("full") branch, exactly as it did here — so camel-microprofile-health does emit error.stacktrace at the default level. CamelMicroProfileHealthCheckTest.testExposureLevelDefault asserts it:

assertEquals("Forced exception", result.getString("error.message"));
assertNotNull(result.getString("error.stacktrace"));

I think the confusion is camel-quarkus-microprofile-health vs camel-microprofile-health. The former is in the camel-quarkus repo and may well behave as you describe; the latter is the one in this repo, and it is the one CAMEL-18832 aligned to — the commit message says "Aligned output to be similar to microprofile-health", and the original implementation already placed the error block outside the branch. So the placement here was deliberate, not accidental.

That doesn't make the change wrong. My reading is that the current behaviour is too verbose for a default and your instinct is right — but as written this PR diverges camel-spring-boot from camel-microprofile-health rather than matching it, which is the opposite of what the description claims, and it leaves a passing test in the other runtime asserting the behaviour you're removing here.

Two ways I can see to resolve it:

1. Change both runtimes together — gate error.stacktrace on full in CamelMicroProfileHealthHelper as well and update testExposureLevelDefault. That delivers what the description says and keeps the alignment CAMEL-18832 established.
2. Accept the divergence deliberately — merge this as-is but drop the microprofile justification from the description, so the guide and the commit history record it as an intentional Spring Boot-only choice rather than an alignment.

Either is fine by me; I just don't think it should land on the current wording. Happy to do the microprofile half if option 1 is the direction — the change there is the same three lines.

For what it's worth, I also think the bigger exposure problem is CAMEL-24498 (your #1927): at Spring Boot's own default of show-details=never none of this reaches an unauthenticated caller at all, and it's the observability starter forcing exposure-level=full and show-details=always that makes it visible.

cc @davsclaus

[Croway]

Thanks Andrea, you are right and the mistake is on our side: camel-microprofile-health does emit error.stacktrace at default, and Camel Quarkus builds its health responses through that same helper, so the MicroProfile/Quarkus sentence was simply wrong.

Let's go with option 1. I'll implement the camel-microprofile-health half and testExposureLevelDefault; this PR should merge together with, or after, that change. The PR description, the commit message and the 4.23 upgrade note entry in apache/camel#26043 are reworded accordingly, and CAMEL-24592 is corrected.

Agreed on CAMEL-24498 being the larger exposure: #1927 removes the forced full and always.

[Croway]

The companion change for camel-microprofile-health is apache/camel#26046.

Claude Code on behalf of Federico Mariani