Skip to content

[2.x] Fix wrong behavior of hasMessageAvailable after seeking by timestamp#342

Merged
Lanayx merged 2 commits intofsprojects:2.xfrom
RobertIndie:cherry-pick-333
Jan 30, 2026
Merged

[2.x] Fix wrong behavior of hasMessageAvailable after seeking by timestamp#342
Lanayx merged 2 commits intofsprojects:2.xfrom
RobertIndie:cherry-pick-333

Conversation

@RobertIndie
Copy link
Contributor

Motivation

Cherry-pick #333 to 2.x branch.

The reader's HasMessageAvailableAsync may return true after a timestamp-based seek, even if there are no available messages in the topic.

Modifications

Add a boolean flag HasSoughtByTimestamp to represent whether the last seek call accepts a timestamp. If it's true, don't take startMessageId into comparison with lastMessageIdInBroker, just compare the mark-delete position and last position in the GetLastMessageId response.

…sprojects#333)

* Fix wrong results of hasMessageAvailable and readNext after seeking by timestamp

* Remove HasSoughtByTimestamp and improve test

(cherry picked from commit e894e66)
@RobertIndie
Copy link
Contributor Author

The CI is failed related to this issue: #343. Could you help try rerun it? @Lanayx

@Lanayx
Copy link
Member

Lanayx commented Jan 28, 2026

@RobertIndie Before we do the backport can you please comment on the two issues

  1. This ticket Unexpected reading behaviour after seeking by time and using HasMessageAvailableAsync #340
  2. I've recently realized that hasSoughtByTimestamp never returns back to false, once set to true it stays there forever. Shouldn't it be reset after subscription is reestablished?

@Lanayx
Copy link
Member

Lanayx commented Jan 28, 2026

The CI is failed related to this issue: #343. Could you help try rerun it? @Lanayx

Done

@RobertIndie
Copy link
Contributor Author

@RobertIndie Before we do the backport can you please comment on the two issues

  1. This ticket Unexpected reading behaviour after seeking by time and using HasMessageAvailableAsync #340
  2. I've recently realized that hasSoughtByTimestamp never returns back to false, once set to true it stays there forever. Shouldn't it be reset after subscription is reestablished?

Thanks! I pushed a PR to address both these issues: #344.

@Lanayx
Copy link
Member

Lanayx commented Jan 29, 2026

Thanks for addressing that PR. Do your want to includes those commits in this PR?

As I side note - it looks like we don't need to support 2.x any longer, based on nuget numbers nobody uses latest 2.x packages.
image

…sprojects#344)

* Fix Reader HasMessageAvailable behavior after seeking by timestamp

* Improve logic

(cherry picked from commit 170cb2f)
@RobertIndie RobertIndie changed the title [2.x] Fix wrong results of hasMessageAvailable after seeking by timestamp [2.x] Fix wrong behavior of hasMessageAvailable after seeking by timestamp Jan 30, 2026
@RobertIndie
Copy link
Contributor Author

Thanks for addressing that PR. Do your want to includes those commits in this PR?

I include that commit to this PR as well now.

As I side note - it looks like we don't need to support 2.x any longer, based on nuget numbers nobody uses latest 2.x packages.

Some of our users are still relying on version 2.x.

@Lanayx Lanayx merged commit a93f4d7 into fsprojects:2.x Jan 30, 2026
2 of 3 checks passed
@Lanayx
Copy link
Member

Lanayx commented Jan 30, 2026

Some of our users are still relying on version 2.x.

Right, but nobody uses versions above 2.16.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants