davsclaus opened a new pull request, #29011: URL: https://github.com/apache/camel/pull/29011
Fixes [CAMEL-26186](https://issues.apache.org/jira/browse/CAMEL-26186). ### 1. The async consumer sent a null result when the reply did not convert `ThriftMethodHandler` completed the asynchronous call with `callback.onComplete(message.getBody(returnType))`. A reply that did not convert was sent as null with no error. For a struct method (`echo`) the client got "echo failed: unknown result". For a method that returns a number (`add`), the generated callback unboxes the null and throws, so the client got no response at all and waited until its socket timed out. Now a new `toReply` helper (used by the sync and the async path) converts the reply with `getMandatoryBody`. For a method with a return type: - no body: `TApplicationException` of type `MISSING_RESULT` (same message as before: "Return type requires not empty body"); - a body that does not convert: `TApplicationException` of type `INTERNAL_ERROR` ("The reply of method X cannot be converted to its return type Y"). The message names only the return type of the IDL, not the reply. The async path sends it with `callback.onError`. A `void` method still ignores the body. ### 2. The sync consumer sent 0 for a null reply of an i32 method `exchange.getIn().getBody(int.class)` turns a null body into `0` (the type converter gives the default of a primitive), so the null check after it never matched. The shared helper checks for no body before it converts, so the client now gets `MISSING_RESULT`. The same applied to `bool` (`false`) and the other primitive return types. ### 3. The producer matched a single non-List argument by its exact class `ThriftUtils.convertObjects2Primitives` mapped the arguments of a List body to the parameter types (`Integer` to `int`, `HashMap` to `Map`, ...), but used `request.getClass()` for a single non-List body. An `Integer` body found no method with one `i32` argument. The mapping is now in one method, `toParameterType`, which both cases use. Small fix in the same method: a `null` element in a List body threw a `NullPointerException`. It now gives the existing "Thrift service client method not found: ...(null)" error (`printParamsTypes` already handled a null type). ### Tests - `ThriftConsumerReplyTest`: embedded sync and async Thrift servers with a Camel consumer on localhost. It checks a null reply for `add`, a Map reply for `add`, null/text/Map replies for `echo`, and a Map reply for the void `ping`, and that the connection still works after each error. Without the fix, 6 of 8 failed: the sync server sent `0`, the async one sent no response, and the error types were wrong. - `ThriftUtilsTest`: unit tests of `invokeSyncMethod` against a fake client. They cover single `Integer`, `Long`, `Boolean`, `HashMap` and `HashSet` bodies, and a null argument in a List. All 4 failed without the fix. - Full module: 76 tests, all pass (`mvn clean install -Psourcecheck`). ### Docs and generated files - `@BodyTypes` `consumerReply` of `ThriftEndpoint` no longer says the asynchronous server sends a null result. Regenerated `thrift.json`, and copied it to the catalog. - `thrift-component.adoc`: added a paragraph on a single argument body, and one on the consumer reply. Copied it to the catalog. - Upgrade guide 4.24: new `camel-thrift` section next to the existing one, because users may rely on the `0` or null result. ### Not changed - A one-argument method whose argument is a list still needs the list wrapped in a List, as documented. - A `null` argument still cannot be passed, because the method is looked up by exact parameter types. Supporting it would need a lookup by name and number of arguments. That is a separate change. _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]
