Skip to content

Conversation

@frankvicky
Copy link
Contributor

@frankvicky frankvicky commented Feb 5, 2026

JIRA: KAFKA-20127
This PR is part of implementation of KIP-1271, adding new methods to
enable storing headers in state store.

@github-actions github-actions bot added triage PRs from the community streams labels Feb 5, 2026
* @param rawKey the key as raw bytes
* @return the key as typed object
*/
@Deprecated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that make sense to replace this deprecated method with the newly introduced one?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose that we should add @SupressWarning and replace them in follow-up PRs.

@frankvicky frankvicky force-pushed the KAFKA-20127 branch 3 times, most recently from 82f39db to 847d808 Compare February 6, 2026 16:31
@@ -149,26 +151,49 @@ public String topic() {
* @param rawKey the key as raw bytes
* @return the key as typed object
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add:

@deprecated Since 4.3. Use {@link #keyFrom(byte[], Headers} instead.

Similar elsewhere.

* @param rawValue the value as raw bytes
* @return the value as typed object
*/
public V valueFrom(final byte[] rawValue, Headers headers) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing final

* @return the value as typed object
*/
public V valueFrom(final byte[] rawValue, Headers headers) {
return valueSerde.deserializer().deserialize(topic, headers, Utils.wrapNullable(rawValue));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to add Utils.wrapNullable -- we don't use it in existing valueFrom(...) either?

* @return the serialized key
*/
public byte[] rawKey(final K key, final Headers headers) {
try {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a lot of code duplication -- should we update existing rawKey(...) to just call this new one, passing in new RecordHeaders() object instead?

* @return the serialized value
*/
@SuppressWarnings("rawtypes")
public byte[] rawValue(final V value, final Headers headers) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question.

}

@Test
public void shouldDeserializeValueWithNullHeaders() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same

}

@Test
public void shouldSerializeKeyWithEmptyHeaders() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This case should be covered implicitly (if we let rawKey(key) call rawKey(key, new RecordHeaders())) via the existing test for rawKey(key). So might be redundant?

}

@Test
public void shouldSerializeValueWithEmptyHeaders() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Redundant as above?

}

@Test
public void shouldThrowIfIncompatibleSerdeForKeyWithHeaders() throws ClassNotFoundException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

}

@Test
public void shouldThrowIfIncompatibleSerdeForValueWithHeaders() throws ClassNotFoundException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

@github-actions github-actions bot removed the triage PRs from the community label Feb 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants