Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

v4.3.3 no longer adds a header "TIMESTAMP" on kafka messages consumed

オープン
  • 何か問題がありますか？
#3,211 コメント 3 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@olegz がすでに取り組んでいます。

2026年8月7日 から。

  • #3245 @PRAHLAD09-dev による — マージされずにクローズ

評価

この issue はまだ評価されていません。

説明

Backport 4.3.x bug

version 4.3.0 used to add a "timestamp" header when consumming kafka messages. version 4.3.3 does not. We used this value and it seemed like a breaking change when it disapeared on a patch bump.

The reason is in how org.springframework.cloud.stream.function.FunctionConfiguration#sanitize was changed in the commit https://github.com/spring-cloud/spring-cloud-stream/commit/d30044b25e13302472fb418de239d7ee1ffa756c .

	private static <P> Message<P> sanitize(Message<P> inputMessage) {
		return MessageBuilder
			.fromMessage(inputMessage)
			.removeHeader("spring.cloud.stream.sendto.destination")
			.setHeader(MessageUtils.SOURCE_TYPE, inputMessage.getHeaders().get(MessageUtils.TARGET_PROTOCOL))
			.removeHeader(MessageUtils.TARGET_PROTOCOL)
			.build();
	}

was changed to :

	private static <P> Message<P> sanitize(Message<P> inputMessage) {
		return MessageBuilder
			.fromMessage(inputMessage)
			.removeHeader("spring.cloud.stream.sendto.destination")
		//	.setHeader(MessageUtils.SOURCE_TYPE, inputMessage.getHeaders().get(MessageUtils.TARGET_PROTOCOL))
		//	.removeHeader(MessageUtils.TARGET_PROTOCOL)
			.build();
	}

The change caused an .build() to behave different since headerAccessor.isModified() now returns false. The builder has an if that has this as a predicate.

public Message<T> build() {
		if (!this.modified && !this.headerAccessor.isModified() && this.originalMessage != null
				&& !containsReadOnly(this.originalMessage.getHeaders())) {

			return this.originalMessage;
		}
		if (this.payload instanceof Throwable throwable) {
			return (Message<T>) new ErrorMessage(throwable, this.headerAccessor.toMap());
		}
		return new GenericMessage<>(this.payload, this.headerAccessor.toMap());
	}

org.springframework.integration.support.BaseMessageBuilder#build would thus return originalMessage instead of using the GenericMessage constructor. And only GenericMessage constructor added a "timestamp" header.

location outside of your repo: (org/springframework/spring-messaging/6.2.18/spring-messaging-6.2.18-sources.jar!/org/springframework/messaging/MessageHeaders.java:151)

To Reproduce
Steps to reproduce the behavior:

  1. Consume a kafka message with a consumer
public class ValidationConsumer implements Consumer<Message<DataBlock>> {

    @Override
    public void accept(Message<DataBlock> message) {
        var messageHeaders = message.getHeaders(); 
 System.out.print(messageHeaders.getTimestamp() )  // v4.3.0 has a value here, v4.3.3 has null

Additional context
We found this when bumping spring-cloud-dependencies from 2025.0.0 to 2025.0.3.

We dont need a quick fix for this. We will change our application code to use our own start time instead of relying on the "timstamp" header that used to be provided by this library. It feels more robust to use our own startime for our own application needs.

主要言語
Java
スター
1.1k
フォーク
647
平均マージ
2日 7時間
マージ済み PR（30日）
5

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

spring-cloud/spring-cloud-stream のほかの issue

spring-cloud/spring-cloud-stream の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。