Completing a service bus message

[adzfaulkner]

Feature Request

Good morning,

Currently it's not possible to complete a service bus message without the original ReceivedMessage struct retrieved from receiver.ReceiveMessages() call.

This is ok if the receive/complete occurs in the same runtime execution but for task I'm currently working on, I require a method of being able to complete a message in a process independent of when the message was originally retrieved / locked.

Thoughts on possible solutions to this problem include providing functioning to allow:

1. Message(s) to completed/abandoned using the message id and lock token
2. Serializing of a given RetreievedMessage so that it can be deserialized at a later time

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @EldertGrootenboer.

[RickWinter]

Attn: @richardpark-msft

[richardpark-msft]

I've looked into this before, and I think we can carve out a way to do this - my original idea was just to set the LockToken property on a ReceivedMessage

One problem I ran into when looking at this is that you can't settle this way with Service Bus sessions. If you're using those we'd need to have the service-side implement that behavior so it's a much bigger conversation.

However, for non-session traffic, I did come up with this solution:

Ignoring all of my obvious test harness setup, you can see how this would work in practice - you'd serialize the 16 bytes of LockToken from your original received message, and then just create another ReceivedMessage, and set LockToken in the process that completes it.

func ExampleReceiver_CompleteMessage_settleWithLockToken() {
	// ReceiveMessages respects the passed in context, and will gracefully stop
	// receiving when 'ctx' is cancelled.
	ctx, cancel := context.WithTimeout(context.TODO(), 60*time.Second)
	defer cancel()

	messages, err = receiver.ReceiveMessages(ctx,
		// The number of messages to receive. Note this is merely an upper
		// bound. It is possible to get fewer message (or zero), depending
		// on the contents of the remote queue or subscription and network
		// conditions.
		1,
		nil,
	)

	if err != nil {
		panic(err)
	}

	for _, message := range messages {
		// The message body is a []byte. For this example we're just assuming that the body
		// was a string, converted to bytes but any []byte payload is valid.
		var body []byte = message.Body
		fmt.Printf("Message received with body: %s\n", string(body))

		// For more information about settling messages:
		// https://docs.microsoft.com/azure/service-bus-messaging/message-transfers-locks-settlement#settling-receive-operations

		// You can settle with just a lock token. This allows you to settle on a separate Receiver instance, or even
		// a Receiver instance in a completely separate process.
		//
		// To do this:
		// 1. Create a ReceivedMessage instance, like this:
		completelySeparateMsg := &azservicebus.ReceivedMessage{
			LockToken: message.LockToken,
		}

		// 2. And settle it like you would any other ReceivedMessage.
		err = receiver.CompleteMessage(context.TODO(), completelySeparateMsg, nil)

		if err != nil {
			var sbErr *azservicebus.Error

			if errors.As(err, &sbErr) && sbErr.Code == azservicebus.CodeLockLost {
				// The message lock has expired. This isn't fatal for the client, but it does mean
				// that this message can be received by another Receiver (or potentially this one!).
				fmt.Printf("Message lock expired\n")

				// You can extend the message lock by calling receiver.RenewMessageLock(msg) before the
				// message lock has expired.
				continue
			}

			panic(err)
		}

		fmt.Printf("Received and completed the message\n")
	}
}

Does this sound like what you wanted to do?

[github-actions]

Hi @adzfaulkner. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[adzfaulkner]

@richardpark-msft first and foremost many thanks for spending the time to respond to the issue I raised.

The workaround you suggested is something similar that I already tried but looks as if the messageSettler.go requires more props than just the lock token to be set on the CompleteMessage struct:

[github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus.(*Receiver).CompleteMessage.(*messageSettler).CompleteMessage.func1({0x7193b6da80e8](http://github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus.(*Receiver).CompleteMessage.(*messageSettler).CompleteMessage.func1(%7B0x7193b6da80e8), 0xc00047c700}, {0x7b9580, 0xc000118370})
/go/pkg/mod/github.com/!azure/azure-sdk-for-go/sdk/messaging/azservicebus@v1.9.0/messageSettler.go:62