[BUG] ServiceBusAdministrationClient.updateSubscription() silently ignores defaultMessageTimeToLive changes

[iamvirul]

Describe the bug

When using ServiceBusAdministrationClient.updateSubscription() to update a subscription's defaultMessageTimeToLive property, the change is silently ignored. The SDK correctly sets the value on the local SubscriptionProperties object, but Azure returns the original (or default infinite) TTL value. No error is thrown.

This issue was introduced in SDK version 7.16.0-beta.1 when Jackson Dataformat XML was replaced with azure-xml. The same issue was previously fixed for queues in PR #32158 (XML element ordering), but the fix was not applied to subscriptions.

Exception or Stack Trace
No exception is thrown. The update silently fails - Azure ignores the TTL change and returns the original value.

To Reproduce
Steps to reproduce the behavior:

1. Create a topic
2. Create a subscription with a specific TTL (e.g., 70000 seconds)
3. Update the subscription with a different TTL (e.g., 50000 seconds)
4. Observe that the returned TTL is not updated (stays at 70000 or reverts to infinite)

Code Snippet

import com.azure.messaging.servicebus.administration.ServiceBusAdministrationClient;
import com.azure.messaging.servicebus.administration.ServiceBusAdministrationClientBuilder;
import com.azure.messaging.servicebus.administration.models.SubscriptionProperties;
import java.time.Duration;

public class SubscriptionTTLUpdateBug {
    public static void main(String[] args) {
        String connectionString = "your-connection-string";
        String topicName = "test-topic";
        String subscriptionName = "test-subscription";

        ServiceBusAdministrationClient adminClient = new ServiceBusAdministrationClientBuilder()
            .connectionString(connectionString)
            .buildClient();

        // Step 1: Create topic
        adminClient.createTopic(topicName);

        // Step 2: Create subscription with TTL = 70000 seconds
        SubscriptionProperties createResult = adminClient.createSubscription(
            topicName,
            subscriptionName,
            new CreateSubscriptionOptions().setDefaultMessageTimeToLive(Duration.ofSeconds(70000))
        );
        System.out.println("Created TTL: " + createResult.getDefaultMessageTimeToLive());
        // Output: Created TTL: PT19H26M40S (70000 seconds) - CORRECT

        // Step 3: Get subscription and update TTL to 50000 seconds
        SubscriptionProperties props = adminClient.getSubscription(topicName, subscriptionName);
        System.out.println("Current TTL before update: " + props.getDefaultMessageTimeToLive());
        // Output: PT19H26M40S (70000 seconds) - CORRECT

        props.setDefaultMessageTimeToLive(Duration.ofSeconds(50000));
        System.out.println("TTL after local set: " + props.getDefaultMessageTimeToLive());
        // Output: PT13H53M20S (50000 seconds) - Local object is correct

        // Step 4: Call updateSubscription
        SubscriptionProperties updateResult = adminClient.updateSubscription(props);
        System.out.println("TTL returned from Azure: " + updateResult.getDefaultMessageTimeToLive());
        // Output: PT256204778H48M5.4775807S (infinite!) - BUG: Azure ignored the update!

        // Step 5: Verify by getting subscription again
        SubscriptionProperties verifyResult = adminClient.getSubscription(topicName, subscriptionName);
        System.out.println("Verified TTL: " + verifyResult.getDefaultMessageTimeToLive());
        // Output: PT256204778H48M5.4775807S (infinite!) - Confirms update was ignored
    }
}

Expected behavior
After calling updateSubscription() with defaultMessageTimeToLive set to 50000 seconds (PT13H53M20S):

• The returned SubscriptionProperties should show TTL = PT13H53M20S
• A subsequent getSubscription() should also return TTL = PT13H53M20S

Actual behavior

• The returned SubscriptionProperties shows TTL = PT256204778H48M5.4775807S (infinite)
• The TTL change is silently ignored
• No error or exception is thrown

Screenshots
N/A

Setup (please complete the following information):

• OS: macOS / Linux / Windows (issue is server-side, OS independent)
• IDE: IntelliJ IDEA
• Library/Libraries:
  • com.azure:azure-messaging-servicebus:7.17.17
  • com.azure:azure-xml:1.2.1
• Java version: 17
• App Server/Environment: Standalone Java application
• Frameworks: None (plain Java)

Additional context

Root Cause Analysis

This issue appears to be related to XML element ordering in the update request. A similar issue was fixed for queues in PR #32158:

• Issue: [BUG] Can't update service bus queue status  #30880
• PR: Fix update queue status failed. #32158

The PR description states: "The updated xml should have exact same order as what we get from service."

The fix for queues reordered XML elements in QueueDescription and TopicDescription, but SubscriptionDescription was not updated.

Workaround

Set defaultMessageTimeToLive during subscription creation instead of updating:

// This works:
adminClient.createSubscription(topicName, subscriptionName,
    new CreateSubscriptionOptions().setDefaultMessageTimeToLive(Duration.ofSeconds(70000)));

// This does NOT work:
SubscriptionProperties props = adminClient.getSubscription(topicName, subscriptionName);
props.setDefaultMessageTimeToLive(Duration.ofSeconds(50000));
adminClient.updateSubscription(props); // TTL change is ignored

Version Information

• Issue introduced in: 7.16.0-beta.1 (Jackson → azure-xml migration)
• Issue confirmed in: 7.17.17
• Last working version: 7.14.x (used Jackson Dataformat XML)

Related Issues

• Servicebus subscription Message TTL changes to weird number when updating forwardTo azure-cli#8424 - "Servicebus subscription Message TTL changes to weird number when updating forwardTo"
• [BUG] Can't update service bus queue status  #30880 - "[BUG] Can't update service bus queue status" (fixed in PR Fix update queue status failed. #32158)

Information Checklist

• Bug Description Added
• Repro Steps Added
• Setup information Added

[github-actions]

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