You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by "RobertIndie (via GitHub)" <gi...@apache.org> on 2025/05/12 10:30:35 UTC
[PR] Fix reader hanging when startMessageId is latest [pulsar-client-go]
RobertIndie opened a new pull request, #1364:
URL: https://github.com/apache/pulsar-client-go/pull/1364
### Motivation
The Go client version 0.15.0 introduced a regression bug. If the reader's `startMessageId` is set to the latest, it will hang while reading. This issue can be reproduced using the new test case: `TestReaderReadFromLatest`.
### Modifications
The root cause is a change in behavior from before version 0.15.0. Previously, the consumer would avoid discarding messages if `startMessageId` was set to Latest. This logic was altered in this pull request: https://github.com/apache/pulsar-client-go/pull/1340/files#diff-782cf41d23c24657ede53da5d028f05819b302305ed676c61322b4cfba4265e9L1454-L1457
The following logic was removed:
```go
// if we start at latest message, we should never discard
if pc.options.startMessageID != nil && pc.options.startMessageID.equal(latestMessageID) {
return false
}
```
In version 0.15.0, if `startMessageId` is Latest, the reader won't receive any messages because all message IDs are before the latest and will be discarded. We need to reinstate this check.
For the seek operation, the correct approach is:
- When handling a seek request, the consumer should set the `seekMessageId` before reconnecting.
- After reconnecting, the consumer should check if `seekMessageId` exists. If it does, it indicates the consumer is seeking, and `seekMessageId` should be set as `startMessageId`. This ensures that even if the reader's `startMessageId` is Latest, it won't receive messages before the specified seek message ID, maintaining the correct behavior as intended in this [PR](https://github.com/apache/pulsar-client-go/pull/1340).
### Does this pull request potentially affect one of the following parts:
*If `yes` was chosen, please highlight the changes*
- Dependencies (does it add or upgrade a dependency): (yes / no)
- The public API: (yes / no)
- The schema: (yes / no / don't know)
- The default values of configurations: (yes / no)
- The wire protocol: (yes / no)
### Documentation
- Does this pull request introduce a new feature? (yes / no)
- If yes, how is the feature documented? (not applicable / docs / GoDocs / not documented)
- If a feature is not applicable for documentation, explain why?
- If a feature is not documented yet in this PR, please create a followup issue for adding the documentation
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Fix reader hanging when startMessageId is latest [pulsar-client-go]
Posted by "Copilot (via GitHub)" <gi...@apache.org>.
Copilot commented on code in PR #1364:
URL: https://github.com/apache/pulsar-client-go/pull/1364#discussion_r2084487685
##########
pulsar/consumer_partition.go:
##########
@@ -1977,7 +1984,11 @@ func (pc *partitionConsumer) grabConn(assignedBrokerURL string) error {
KeySharedMeta: keySharedMeta,
}
- pc.startMessageID.set(pc.clearReceiverQueue())
+ if seekMsgID := pc.seekMessageID.get(); seekMsgID != nil {
+ pc.startMessageID.set(seekMsgID)
Review Comment:
[nitpick] After using seekMessageID to update startMessageID, consider resetting seekMessageID to nil to avoid the state persisting across subsequent reconnects.
```suggestion
pc.startMessageID.set(seekMsgID)
pc.seekMessageID.set(nil) // Reset seekMessageID to nil to avoid persisting state across reconnects
```
##########
pulsar/reader_test.go:
##########
@@ -1237,3 +1239,60 @@ func TestReaderWithSeekByTime(t *testing.T) {
})
}
}
+
+func TestReaderReadFromLatest(t *testing.T) {
+ topic := newTopicName()
+ client, err := NewClient(ClientOptions{
+ URL: lookupURL,
+ })
+
+ assert.Nil(t, err)
Review Comment:
[nitpick] Consider using require.NoError(t, err) instead of assert.Nil(t, err) for client creation to ensure immediate test termination on error and maintain consistency within the test.
```suggestion
require.NoError(t, err)
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org