oscerd opened a new pull request, #25685: URL: https://github.com/apache/camel/pull/25685
Fixes [CAMEL-24428](https://issues.apache.org/jira/browse/CAMEL-24428). ## The Knative consumer returns the stack trace to the caller `KnativeHttpConsumer.computeResponseBody()` puts the exception's full stack trace in the response body whenever the exchange failed, unconditionally: ```java if (exception != null) { // we failed due an exception so print it as plain text final String stackTrace = ExceptionHelper.stackTraceToString(exception); // the body should then be the stacktrace body = stackTrace.getBytes(StandardCharsets.UTF_8); message.setHeader(Exchange.CONTENT_TYPE, "text/plain"); ``` Measured against the unfixed code, a caller of a failing `from("knative:endpoint/...")` route receives: ``` java.lang.RuntimeException: the-internal-detail-a-caller-must-not-see at org.apache.camel.component.knative.http.KnativeHttpTest.lambda$invokeFailingConsumer$46(...) at org.apache.camel.support.processor.DelegateSyncProcessor.process(DelegateSyncProcessor.java:67) at org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$SimpleTask.handleFirst(...) ... ``` [CAMEL-23651](https://issues.apache.org/jira/browse/CAMEL-23651) aligned the HTTP consumers on a `muteException` option defaulting to `true`. It exists in `camel-http-common` (and therefore `camel-servlet` and `camel-jetty`), `camel-http`, `camel-netty-http`, `camel-platform-http` and `camel-undertow`. `camel-knative` has no equivalent — a grep for `muteException` across `components/` still shows the option in the http family only. ## The change A `muteException` consumer option on `KnativeConfiguration`, defaulting to `true`, carried down to the consumer through `KnativeTransportConfiguration`. `computeResponseBody` then follows the same shape `VertxPlatformHttpSupport.handleExceptions` uses. **One thing worth a reviewer's eye:** the muted body is an *empty* byte array, not `null`. The caller in `KnativeHttpConsumer` does: ```java if (body != null) { request.response().end(body); } else { request.response().setStatusCode(204); request.response().end(); } ``` so returning `null` would have replaced the 500 with a **204 No Content** — turning a hidden stack trace into a hidden failure. The tests pin the status alongside the body for exactly that reason. ## Compatibility `KnativeTransportConfiguration` is public SPI (`camel-knative-api`). It gains a four-argument constructor; the existing three-argument one is retained and delegates with `muteException = true`, so existing code compiles and links unchanged and picks up the new default. The response status is unchanged — a failed exchange still returns 500, or whatever `CamelHttpResponseCode` the route set. Only the body changes. Upgrade-guide entry included, showing `knative:endpoint/myEndpoint?muteException=false` for a route that relies on the detail. ## Scope CAMEL-24428 originally covered four consumers. It has been rescoped to `camel-knative` and the other three are tracked separately, so each can be fixed and released on its own: [CAMEL-24476](https://issues.apache.org/jira/browse/CAMEL-24476) (mina), [CAMEL-24477](https://issues.apache.org/jira/browse/CAMEL-24477) (cxf), [CAMEL-24478](https://issues.apache.org/jira/browse/CAMEL-24478) (grpc). ## Testing Two tests added to `KnativeHttpTest`, both run across every `CloudEvents` version: * `aFailedExchangeDoesNotReturnTheStackTraceByDefault` — asserts the body carries nothing of the route's exception **and** that the status is still 500. Verified RED against unfixed code (3/3 CloudEvent variants), with the stack trace above as the actual value. * `muteExceptionFalseRestoresTheStackTraceInTheResponse` — the opt-out still works. Suites run: `camel-knative-api` 3/3 · `camel-knative-component` 4/4 · `camel-knative-http` 171/171 · full `mvn clean install -DskipTests` across the reactor. _Claude Code on behalf of oscerd_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
