[jira] [Updated] (CAMEL-19065) Saga Long-Running-Action header propagation is broken with Kafka Component

["Jose A. Iñigo (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-19065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jose A. Iñigo updated CAMEL-19065:
----------------------------------
    Description: 
As reported in the camel.zulipchat.com #camel stream, it seems that camel saga async workflows using the Kafka component might be losing the correlation between the original LRA header value since the Kafka component doesn't automatically turn it back into a String.

Given the following route:
{code:java}
        from("direct:bookings")
            .saga()
            .propagation(MANDATORY)
           .log("LOG1 \${headers}")
            .to("kafka:booking-requests?brokers=localhost:9092")

       from("kafka:booking-responses?brokers=localhost:9092")
            .saga()
            .propagation(MANDATORY)
            .log("LOG2 \${headers}") {code}
When printing the headers we can see the Long-Running-Action with a String value:

 
{code:java}
LOG1 ...,Long-Running-Action=90EA3C7D191D45E-0000000000000001, ... {code}
 

 

This headers are serialized as bytes by the Kafka Producer and sent to a topic _booking-requests_ where a processing application reads them and writes them back to {_}booking-responses{_}.

The problem shows up in the second log statement, where the Long-Running-Action header is not 90EA3C7D191D45E-0000000000000001 anymore:

 
{code:java}
LOG2 Long-Running-Action=[B@4d4b56e8 {code}
 

The Camel Saga component isn't automatically reformating the header value into a String.

As a workaround we can provide a KafkaHeaderDeserializer to reconstruct it as a String:

 
{code:java}
       from("kafka:booking-responses?brokers=localhost:9092&headerDeserializer=#kafkaHeaderStringDeserializer")
            .saga()
            .propagation(MANDATORY)
            .log("LOG2 \${headers}") {code}
 

Here's a sample project where you can check this behaviour: https://github.com/codependent/booking-service

  was:
As reported in the camel.zulipchat.com #camel stream, it seems that camel saga async workflows using the Kafka component might be losing the correlation between the original LRA header value since the Kafka component doesn't automatically turn it back into a String.

Given the following route:
{code:java}
        from("direct:bookings")
            .saga()
            .propagation(MANDATORY)
           .log("LOG1 \${headers}")
            .to("kafka:booking-requests?brokers=localhost:9092")

       from("kafka:booking-responses?brokers=localhost:9092")
            .saga()
            .propagation(MANDATORY)
            .log("LOG2 \${headers}") {code}
When printing the headers we can see the Long-Running-Action with a String value:

 
{code:java}
LOG1 ...,Long-Running-Action=90EA3C7D191D45E-0000000000000001, ... {code}
 

 

This headers are serialized as bytes by the Kafka Producer and sent to a topic _booking-requests_ where a processing application reads them and writes them back to {_}booking-responses{_}.

The problem shows up in the second log statement, where the Long-Running-Action header is not 90EA3C7D191D45E-0000000000000001 anymore:

 
{code:java}
LOG2 Long-Running-Action=[B@4d4b56e8 {code}
 

The Camel Saga component isn't automatically reformating the header value into a String. 

As a workaround we can provide a KafkaHeaderDeserializer to reconstruct it as a String:

 
{code:java}
       from("kafka:booking-responses?brokers=localhost:9092&headerDeserializer=#kafkaHeaderStringDeserializer")
            .saga()
            .propagation(MANDATORY)
            .log("LOG2 \${headers}") {code}
 

 


> Saga Long-Running-Action header propagation is broken with Kafka Component
> --------------------------------------------------------------------------
>
>                 Key: CAMEL-19065
>                 URL: https://issues.apache.org/jira/browse/CAMEL-19065
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-kafka, camel-lra
>    Affects Versions: 3.20.2
>            Reporter: Jose A. Iñigo
>            Priority: Major
>
> As reported in the camel.zulipchat.com #camel stream, it seems that camel saga async workflows using the Kafka component might be losing the correlation between the original LRA header value since the Kafka component doesn't automatically turn it back into a String.
> Given the following route:
> {code:java}
>         from("direct:bookings")
>             .saga()
>             .propagation(MANDATORY)
>            .log("LOG1 \${headers}")
>             .to("kafka:booking-requests?brokers=localhost:9092")
>        from("kafka:booking-responses?brokers=localhost:9092")
>             .saga()
>             .propagation(MANDATORY)
>             .log("LOG2 \${headers}") {code}
> When printing the headers we can see the Long-Running-Action with a String value:
>  
> {code:java}
> LOG1 ...,Long-Running-Action=90EA3C7D191D45E-0000000000000001, ... {code}
>  
>  
> This headers are serialized as bytes by the Kafka Producer and sent to a topic _booking-requests_ where a processing application reads them and writes them back to {_}booking-responses{_}.
> The problem shows up in the second log statement, where the Long-Running-Action header is not 90EA3C7D191D45E-0000000000000001 anymore:
>  
> {code:java}
> LOG2 Long-Running-Action=[B@4d4b56e8 {code}
>  
> The Camel Saga component isn't automatically reformating the header value into a String.
> As a workaround we can provide a KafkaHeaderDeserializer to reconstruct it as a String:
>  
> {code:java}
>        from("kafka:booking-responses?brokers=localhost:9092&headerDeserializer=#kafkaHeaderStringDeserializer")
>             .saga()
>             .propagation(MANDATORY)
>             .log("LOG2 \${headers}") {code}
>  
> Here's a sample project where you can check this behaviour: https://github.com/codependent/booking-service



--
This message was sent by Atlassian Jira
(v8.20.10#820010)