[Service Bus] Fix spurious DeliveryNotOnLinkException in session processor (#47356)

[ksalazar-91]

Summary

Fixes #47356.

A session-enabled ServiceBusProcessorClient (PEEK_LOCK) that settles messages manually inside the handler — e.g. calling context.complete() — while auto-complete is left enabled (the default) intermittently logged a spurious error at ERROR:

c.a.c.a.implementation.handler.ReceiveLinkHandler2 - {"az.sdk.message":"Cannot process the
disposition request to set the state as 'Accepted{}' for the delivery with delivery tag (id)
'...'. Reason: The delivery with the delivery tag does not exist in the link's DeliveryMap.", ...}

The message is already settled correctly on the broker; the only symptom is this misleading DeliveryNotOnLinkException log line (one per message). No messages are lost or redelivered, and processError is not invoked.

Root cause

The processor's auto-disposition feature settles a message after the handler returns. When the handler also settles manually, two dispositions are issued for the same delivery. The SDK is designed to absorb this redundant settle via the message.isSettled() guard in updateDisposition:

} else if (message.isSettled()) {
    return Mono.error(new IllegalArgumentException("The message has either been deleted or already settled."));
}

The non-session and V1-session paths arm this guard by calling message.setIsSettled() on a successful disposition (ServiceBusReceiverAsyncClient). The V2 session path (SessionsMessagePump.SessionReceiversTracker.updateDisposition) never did. So the flag stayed false, the guard could not trip, and the redundant auto-complete proceeded to a second link-level disposition on a delivery that had already been removed from the DeliveryMap — producing the DeliveryNotOnLinkException ERROR.

Fix

Mark the message settled on a successful disposition in the V2 session path, mirroring the sibling paths:

updateDispositionMono = receiver.updateDisposition(message.getLockToken(), deliveryState)
    .doOnSuccess(__ -> message.setIsSettled());

This arms the existing isSettled() guard so a redundant settle short-circuits with the benign "already settled" error (swallowed at verbose by the auto-disposition wrapper) instead of reaching the receive-link. The change is package-local to azure-messaging-servicebus; no azure-core-amqp change is needed.

Verification

Reproduced live against a Standard namespace with a session-enabled subscription, sending 5 messages to one session and a session processor that calls complete() manually with auto-complete enabled.

Version	disableAutoComplete()	Messages settled	processError	DeliveryNotOnLinkException logged
7.17.16 (reported)	off	5/5	0	yes
7.17.18 (latest, amqp 2.11.4)	off	5/5	0	yes
This PR (7.18.0-beta.2)	off	5/5	0	no ✅
This PR (7.18.0-beta.2)	on	5/5	0	no ✅

The fix removes the error log with auto-complete still enabled (no customer config change required) and does not regress the manual-settlement path.

Notes for reviewers

• Using disableAutoComplete() remains the recommended pattern when settling manually; this PR additionally makes the SDK fail quietly and consistently on a redundant settle for session processors, matching the documented "auto-settle is tolerated" behavior already present in the other receive paths.
• CHANGELOG updated under 7.18.0-beta.2 (Unreleased) → Bugs Fixed.

[github-actions]

Thank you for your contribution @ksalazar-91! We will review the pull request and get back to you soon.

[Copilot]

Pull request overview

This PR fixes a misleading DeliveryNotOnLinkException ERROR log that can occur in session-enabled ServiceBusProcessorClient when a message is settled manually inside the handler while auto-complete is still enabled, by ensuring the V2 session disposition path marks messages as settled after a successful disposition.

Changes:

• Mark ServiceBusReceivedMessage as settled (message.setIsSettled()) after a successful disposition in the V2 session path to activate the existing message.isSettled() guard on redundant settlements.
• Add a release note describing the removed spurious error log and clarifying that broker settlement was already succeeding.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
sdk/servicebus/azure-messaging-servicebus/src/main/java/com/azure/messaging/servicebus/SessionsMessagePump.java	Marks messages as settled on successful session disposition to prevent redundant settle attempts from reaching the receive-link.
sdk/servicebus/azure-messaging-servicebus/CHANGELOG.md	Documents the bug fix in 7.18.0-beta.2 (Unreleased) under “Bugs Fixed”.

[ksalazar-91]

Added a regression test in the latest push (commit 5e9b2ff): SessionsMessagePumpIsolatedTest#shouldNotReDispositionWhenHandlerSettlesWithAutoCompleteEnabled. It runs a session message through the pump with auto-complete enabled and a handler that calls complete() manually, then asserts (1) message.isSettled() becomes true (setIsSettled() invoked once), and (2) the receive-link sees exactly one updateDisposition call — proving the redundant auto-settlement short-circuits at the isSettled() guard and never issues a second disposition that would raise DeliveryNotOnLinkException. Verified passing (3/3 with related disposition tests); checkstyle + spotbugs clean.