[improve][pip] PIP-423: Add Support for Cancelling Individual Delayed Messages

[Denovo1998]

Motivation

In modern event-driven architectures, the ability to react to changing conditions is crucial. While Pulsar's delayed message feature is valuable for scheduling future tasks or deliveries, the lack of a cancellation mechanism presents a limitation. Use cases where cancellation is important include:

• An order is placed with delayed processing, but the user cancels the order before processing begins.
• A scheduled notification becomes obsolete due to a subsequent user action.
• System alerts scheduled for future delivery are resolved before the delivery time.

Without a cancellation feature, applications might resort to workarounds, such as:

• Consumers receiving and then filtering/ignoring obsolete delayed messages, which wastes processing resources and bandwidth.
• Maintaining complex state management on the client-side to track and ignore messages, which is error-prone and doesn't prevent the message from being delivered by the broker.

This proposal aims to introduce a robust mechanism to cancel delayed messages directly at the subscription level, preventing their delivery if they are no longer needed.

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository: apache#24370

[Copilot]

Pull Request Overview

This PR introduces PIP-423, a proposal for adding a new admin API to acknowledge/skip individual messages in Pulsar subscriptions by their specific MessageId.

• Introduces a new REST API endpoint and CLI command to skip specific messages by their MessageId (ledgerId:entryId:batchIndex)
• Leverages existing individual acknowledgement mechanisms for reliability
• Supports both full entry and partial batch message acknowledgements

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Grammatical error: "more then" should be "more than".

[Copilot]

Grammatical error: "more then" should be "more than".

[Copilot]

[nitpick] The "Alternatives" section is empty. While this may be intentional, it's typically good practice to include at least a brief discussion of alternative approaches that were considered and why they were rejected, or explicitly state that no alternatives were considered.

Suggested change

	The main alternative considered was to extend the existing `skip(numMessages)` API to allow skipping by `MessageId`. However, this approach was rejected because it would complicate the semantics of the existing API and could introduce ambiguity when skipping messages in batches or with delayed delivery. No other alternatives were identified that would provide the same level of precision and operational safety as the proposed admin API.