grishaf opened a new pull request, #1486: URL: https://github.com/apache/pulsar-client-go/pull/1486
### Motivation The Pulsar wire protocol's `CommandSubscribe` has a `priority_level` field, and the Java client exposes it via `ConsumerBuilder.priorityLevel(int)`. The Go client currently hardcodes `PriorityLevel: nil`, making it impossible for Go consumers to set their priority level. This is needed for: - **Shared subscriptions**: controlling which consumers the broker prioritizes when dispatching messages (0 = max priority, higher numbers = lower priority) - **Failover subscriptions on partitioned topics**: controlling which consumer becomes the active consumer based on priority level and lexicographic consumer name sorting Master Issue: https://github.com/apache/pulsar/issues/134 A prior attempt was made in #783 but was closed without merge because it lacked tests and had a validation bug (rejecting priority level 0, which is the valid default/max priority). This PR addresses both issues. ### Modifications 1. **`pulsar/consumer.go`**: Added `PriorityLevel int` field to `ConsumerOptions` with documentation matching the Java client's `ConsumerBuilder.priorityLevel()` javadoc. 2. **`pulsar/consumer_impl.go`**: - Added validation to reject negative priority levels (returns `InvalidConfiguration` error), matching Java's `IllegalArgumentException`. - Threaded `PriorityLevel` through `newPartitionConsumerOpts()`. 3. **`pulsar/consumer_partition.go`**: - Added `priorityLevel int` to `partitionConsumerOpts` struct. - Changed `PriorityLevel: nil` to `PriorityLevel: proto.Int32(int32(pc.options.priorityLevel))` in `grabConn()` so the priority is sent in the `CommandSubscribe` message. 4. **`pulsar/consumer_test.go`**: Added three integration tests: - `TestConsumerWithInvalidPriorityLevel` — validates negative priority is rejected - `TestConsumerSharedWithPriorityLevel` — validates two shared consumers with different priorities can both receive messages - `TestPartitionTopic_ActiveConsumerChangedWithPriority` — validates that on a partitioned failover topic, a higher-priority consumer takes over as active consumer ### Verifying this change This change added tests and can be verified as follows: - `TestConsumerWithInvalidPriorityLevel` verifies that negative priority levels are rejected at subscribe time - `TestConsumerSharedWithPriorityLevel` verifies that consumers with different priority levels on a shared subscription both receive messages correctly - `TestPartitionTopic_ActiveConsumerChangedWithPriority` verifies that on a partitioned failover topic, the consumer with higher priority (lower number) becomes the active consumer ### Does this pull request potentially affect one of the following parts: - Dependencies (does it add or upgrade a dependency): no - The public API: yes (adds `PriorityLevel` field to `ConsumerOptions`) - The schema: no - The default values of configurations: no (default `0` matches previous behavior of `nil` — both mean max priority) - The wire protocol: no (uses existing `priority_level` field in `CommandSubscribe`) ### Documentation - Does this pull request introduce a new feature? yes - If yes, how is the feature documented? GoDocs on the `PriorityLevel` field Made with [Cursor](https://cursor.com) -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
