spring-cloud-contract: Adding kafka message key to a contract, causes assertion fail on producer side

Consumer side application requires events with filled in kafka message key. To add a kafka message key to the contract I need to add:

header('kafka_messageKey', 'keyValue')

When I do it, a new assertion is add to the generated contract test:

response.getHeader('kafka_messageKey')?.toString() == 'keyValue'

And of course test fails because no such header is present.

Expected behaviour: Assertion in generated tests should not be added for ‘kafka_messageKey’ header. Or kafka message key should be added in another way. Eg.:

outputMessage {
    sentTo('...')
    key('keyValue')
    body(...)
    headers {...}
}

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 2
Comments: 15 (8 by maintainers)

Commits related to this issue

Adds support for Kafka message keys in contracts Fixes gh-1267 — committed to onobc/spring-cloud-contract by onobc 4 years ago
Adds support for Kafka message keys in contracts Fixes gh-1267 — committed to onobc/spring-cloud-contract by onobc 4 years ago
Adds support for Kafka message keys in contracts Fixes gh-1267 — committed to onobc/spring-cloud-contract by onobc 4 years ago
Adds support for Kafka message keys in contracts (#1585) * Adds support for Kafka message keys in contracts * Updated doc to include note on Kafka key SerDes * Removes unintentional changes fro... — committed to spring-cloud/spring-cloud-contract by onobc 3 years ago

Most upvoted comments

I should have the submitted tomorrow. I have been fighting a Kafka Streams dumpster fire for the last 24 hours. Just wanted to follow up as my last message said “blah blah blah w/in 24 hours”.

onobc on Dec 18, 2020

I have fixed the main issue in the ticket and am now synthesizing the other header values back into the consumer record.

However, that revealed another issue in that the Receiver consumer is hardcoded to use <int, String> for its <k, v> SerDe (as per KafkaTestUtils.consumerProps). This revealed itself by the headerValue (in the ticket description) being deserialized into something like 4354456 (its int deserialization form).

I have changed this to leverage the spring.kafka.consumer props. This now lets us use any arbitrary key, value (including json object keys). I am working through one last thing then I will get some tests in place (we are a bit thin wrt to the Kafka messaging ones). Should be wrapped up w/in the next 24 hours.

onobc on Dec 15, 2020

@marcingrzejszczak I am taking a look at this and should have something in for review w/in next 24 hours.

onobc on Dec 14, 2020

Facing the same problem while creating contracts for my application. Sending the key works but receiving a key does not work. I debugged KafkaStubMessages.java and saw that the key ist not used while transforming the ConsumerRecord into a Message.

nekator on Dec 1, 2020