oscerd opened a new pull request, #27213: URL: https://github.com/apache/camel/pull/27213
_Claude Code on behalf of oscerd_ Jira: [CAMEL-25227](https://issues.apache.org/jira/browse/CAMEL-25227), a follow-up to CAMEL-24158. ## Problem A route that consumes from one Event Hub and produces to another, `from("azure-eventhubs:...").to("azure-eventhubs:...")`, trips over the `CamelAzureEventHubsPartitionKey` and `CamelAzureEventHubsPartitionId` headers that the consumer sets. The producer prefers both headers over its endpoint options and rejects a partition key together with a partition id, so: - every event with a partition key failed with `Both partitionKey and partitionId are set`, whatever the producer configuration; - with `partitionKey` configured on the producer, every event failed; - with `partitionId` configured, the configured value was replaced by the partition the event was received from, which may not exist on the target hub. CAMEL-24158 only stopped setting a null `PartitionKey` header, which never triggered the error. The same change made `EventHubsComponent` extend `HeaderFilterStrategyComponent`, but no default strategy is ever installed. `getHeaderFilterStrategy()` is therefore null and the producer still copies every header onto the `EventData` application properties, unlike what the 4.14/4.18/4.22 upgrade guides say. The consumer's own `CamelAzureEventHubsEnqueuedTime` (a `java.time.Instant`) then cannot be encoded by the SDK, so a default bridging route failed for every event. ## Changes - `EventHubsConsumer` records the partition id and key of the received event as (internal) exchange properties. - `EventHubsConfigurationOptionsProxy` does not take a partition header that still holds the received value as a partition chosen by the route. `EventHubsProducerOperations` falls back to the received partition key only when neither the route nor the endpoint chose a partition, and never reuses the received partition id. - The resulting order is: a header set by the route, then the `partitionKey`/`partitionId` option, then the received partition key, then Event Hubs' own choice. - Exchanges that do not come from an azure-eventhubs consumer behave exactly as before: a header still overrides the endpoint option, and a key and an id set together still fail. - `EventHubsComponent` installs a `DefaultHeaderFilterStrategy` in `doInit` when none is configured, following the same pattern as `SpringRabbitMQComponent`. - Docs: the component page describes the partition selection order, and the 4.23 upgrade guide has an entry for both behaviour changes. ## Tests `EventHubsConsumerToProducerTest` builds the exchange through the consumer's own mapping and sends it through the real producer endpoint with a mocked `EventHubProducerAsyncClient`. It covers: - keyed and unkeyed events, each with no option, `partitionKey` and `partitionId`; - a partition chosen by the route after consuming; - unchanged behaviour for exchanges not coming from a consumer; - `Camel*` headers not being sent as event properties. 7 of its 9 tests fail on the previous code. The other 2 cover the unchanged behaviour and pass on both. The module's unit tests pass (29/29), and the full reactor `mvn clean install -DskipTests -DskipITs` is green. 🤖 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]
