davsclaus opened a new pull request, #28896: URL: https://github.com/apache/camel/pull/28896
Fixes [CAMEL-26119](https://issues.apache.org/jira/browse/CAMEL-26119). ## 1. A JSON body as bytes or a stream is rejected **What was wrong:** `ProcessProcessor`, `JobProcessor` and `MessageProcessor` read JSON only when the body was a `String`. A JSON body as `byte[]` or an `InputStream` (as an HTTP consumer gives) failed with "Process data missing", "Job data missing" or "Message data missing". **What changed:** a new `readJson` helper in `AbstractBaseProcessor` converts the body to a `String` with the type converter and reads it as JSON. `ProcessProcessor` and `MessageProcessor` use it for any non-null body that is not a request object. `JobProcessor` keeps its order: a `String` is read as JSON first; a `JobWorkerMessage`, or the `CamelCamundaJobKey` header (with a `Map` of variables), comes next; any other body is read as JSON last. So a `byte[]` body with the job key header still takes the header path, as before. ## 2. The consumer's JSON uses other property names than the producer's **Not changed:** the consumer's JSON (camelCase, `variablesAsMap`) is kept. Renaming it to snake_case would break routes that read it (for example JSONPath on `$.bpmnProcessId`). **What changed:** the job operations now use the `CamelCamundaJobKey` header when the JSON (or `JobRequest`) has no job key. Before, the JSON of a worker with `formatJSON=true` sent to `completeJob` gave a `JobRequest` with job key `0`, so the call failed and the route did not see it (bug 3). Now it completes the job. The doc says what property names the worker's JSON uses. **Open question:** should the consumer's JSON switch to snake_case to match the producer, with an upgrade-guide entry? I left it as it is. ## 3. A failed operation does not fail the exchange **What was wrong:** `CamundaService` catches every error of the Camunda client and returns a response with `success=false`. The exchange completed as if the operation had worked. **What changed:** after the response is set, the producer throws a `CamelExchangeException` ("Camunda operation startProcess failed: <message>") when `success` is false. The response stays in the body. `deployResource` still sets its `CamelCamundaIsSuccess`, `CamelCamundaErrorMessage` and `CamelCamundaErrorCode` headers first. In a worker route, `completeJob`, `failJob` and `throwError` still set the `CamundaJobHandled` property, so a failed explicit call is not auto-failed again by the consumer. **Not changed:** the exception does not carry the original client exception as its cause, because `CamundaService` keeps only the message. The service still logs the error with its stack trace. ## Tests The new `CamundaProducerTest` uses a mocked `CamundaService`. It covers JSON as `byte[]` and `InputStream` for startProcess, cancelProcess, publishMessage and completeJob; worker JSON plus the job key header for completeJob; and a failed startProcess, completeJob, publishMessage and deployResource. 9 of its 11 tests fail without the fix. The other 2 guard the "data missing" error and a successful call. The module has 23 tests and all pass. `-Psourcecheck` is clean. ## Docs - `camunda-component.adoc`: JSON from bytes/streams, a failed operation fails the exchange, the worker's JSON property names, and the job key header fallback. The catalog copy is regenerated. - Upgrade guide 4.24: new entry "camel-camunda - a failed operation fails the exchange". _Claude Code on behalf of Claus Ibsen (davsclaus)_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
