unable to create a scheduled message in azure service bus

Hans 25 Reputation points
2025-10-05T07:43:45.4933333+00:00

When creating a scheduled message in azure service bus, it always return connlost error.

I am using golang library:

github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus v1.10.0

the code

sequenceNumbers, err := sender.ScheduleMessages(ctx, []*azservicebus.Message{sbMessage}, scheduledTimeUTC, nil)

always return connlost error. I can confirm that the scheduledTimeUTC is valid and, sending a normal message to the same queue works fine, and creating a scheduled message in Azure portal works fine as well.

Here is the full function code.

func (serviceBus *ServiceBus) sendToQueueScheduled(queueName string, message ServiceBusMessage, scheduledTime time.Time) (int64, *exception.Exception) {
	// Validate scheduled time - must be in the future
	now := time.Now().UTC()
	scheduledTimeUTC := scheduledTime.UTC()
	if scheduledTimeUTC.Before(now) {
		err := fmt.Errorf("scheduled time must be in the future: scheduled=%s, now=%s", scheduledTimeUTC.Format(time.RFC3339), now.Format(time.RFC3339))
		serviceBus.logger.ErrorFunction(err, queueName, message)
		return 0, exception.NewException(types.ExceptionTypeInternalServer)
	}
	// Get or create a long-lived sender for the queue
	sender, err := serviceBus.getSender(queueName)
	if err != nil {
		serviceBus.logger.ErrorFunction(err, queueName, message)
		return 0, exception.NewException(types.ExceptionTypeInternalServer)
	}
	// Convert data to JSON
	dataBytes, err := json.Marshal(message.Data)
	if err != nil {
		serviceBus.logger.ErrorFunction(err, queueName, message)
		return 0, exception.NewException(types.ExceptionTypeInternalServer)
	}
	// Create the Service Bus message
	sbMessage := &azservicebus.Message{
		Body: dataBytes,
	}
	if message.ID != "" {
		sbMessage.MessageID = &message.ID
	}
	if message.Subject != "" {
		sbMessage.Subject = &message.Subject
	}
	if message.ContentType != "" {
		sbMessage.ContentType = &message.ContentType
	}
	if len(message.Properties) > 0 {
		sbMessage.ApplicationProperties = make(map[string]any)
		maps.Copy(sbMessage.ApplicationProperties, message.Properties)
	}
	if message.TimeToLive != nil {
		sbMessage.TimeToLive = message.TimeToLive
	}
	// Schedule message with extended timeout (2 minutes for scheduling operations)
	ctx, cancel := context.WithTimeout(context.Background(), 2*time.Minute)
	defer cancel()
	// get sequence number
	sequenceNumbers, err := sender.ScheduleMessages(ctx, []*azservicebus.Message{sbMessage}, scheduledTimeUTC, nil)
	if err != nil {
		serviceBus.logger.ErrorFunction(err, queueName, message, scheduledTimeUTC)
		return 0, exception.NewException(types.ExceptionTypeInternalServer)
	}
	if len(sequenceNumbers) == 0 {
		serviceBus.logger.ErrorFunction(fmt.Errorf("no sequence number returned"), queueName, message)
		return 0, exception.NewException(types.ExceptionTypeInternalServer)
	}
	serviceBus.logger.Infof("successfully scheduled message to queue: %s, messageID: %s, scheduledTime: %s, sequenceNumber: %d",
		queueName, message.ID, scheduledTimeUTC.Format(time.RFC3339), sequenceNumbers[0])
	return sequenceNumbers[0], nil
}

any urgent help is appreciated, thank you community!

Azure Service Bus
Azure Service Bus
An Azure service that provides cloud messaging as a service and hybrid integration.
0 comments No comments
{count} votes

Answer accepted by question author
  1. Alex Burlachenko 18,390 Reputation points Volunteer Moderator
    2025-10-06T07:53:33.81+00:00

    hi Hans

    Your code looks perfectly correct, and the fact that normal sends work but scheduled messages fail with a connlost error points directly to a potential issue in the Go SDK's handling of the scheduling AMQP link.

    This kind of error often happens when the underlying AMQP connection for the scheduling operation is dropped or times out before the broker can acknowledge the scheduled message.

    Here are a few things to try to troubleshoot and work around this:

    1. Check your scheduled time horizon: Azure Service Bus has a maximum limit for how far in the future you can schedule a message (I believe it's up to 7 days). If your scheduledTimeUTC is beyond this limit, it could cause an unexpected failure that manifests as a connection loss. Double-check that your scheduled time is within the supported range.

    Try a much shorter timeout: You're using a 2-minute timeout, which is quite long. Sometimes, a shorter, more aggressive timeout can help isolate whether this is a genuine connection issue or a protocol-level problem. Try reducing it to 30 seconds to see if the failure mode changes.

    Enable client-side logging: The Azure SDK for Go has built-in logging that can reveal the exact AMQP-level error. Enable debug logging to see what's happening under the hood. You can do this by setting the environment variable AZURE_SDK_GO_LOGGING to all before running your application.

    Consider a workaround pattern: As an immediate workaround to unblock yourself, you could implement a "scheduling" mechanism yourself. Instead of using the built-in scheduled messages, send a normal message with a property indicating the desired enqueue time. Then, have a separate processor function that receives these messages, checks the timestamp, and re-sends them to the actual target queue if the current time has passed the scheduled time. It's more work, but it's reliable.

    Given the specificity of this issue, it's also worth checking the GitHub issues for the azure-sdk-for-go repository to see if others have reported similar problems with the ScheduleMessages function in your version (v1.10.0).

    regards,

    Alex

    and "yes" if you would follow me at Q&A - personaly thx.
    P.S. If my answer help to you, please Accept my answer
    

    https://ctrlaltdel.blog/


1 additional answer

Sort by: Most helpful
  1. Hans 25 Reputation points
    2025-10-10T09:24:58.3933333+00:00

    after digging into the source code, I finally figured out the error, it was becuase one of the field in the message content is a custom type, it retried 3 times and eventually timed out.

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.