Cloud Service Swap Operation Failure — Immediate Error During Swap

Question

Cloud Service Swap Operation Failure — Immediate Error During Swap

logtag 15

Problem description

I am experiencing an issue with swapping deployments between my Azure Cloud Services (Extended Support). The swap operation, which previously completed successfully for many years, now fails almost immediately with the error: 'There was an error processing your request. Try again in a few moments.' This failure occurs within seconds of initiating the swap, and there is no detailed error message provided.

Environment

Azure Cloud Service (Extended Support) for Worker roles, involving two swappable deployments in the Azure public cloud, on a Pay-As-You-Go subscription.

What I've already tried

I have verified that both cloud services are in the 'provisioningState: Succeeded' status and that their 'swappableCloudService.id' properties point correctly to each other using Azure portal JSON view and az CLI commands. I have also checked the activity logs for failed swap events and reviewed the deployment history, but no specific issues or recent changes have been identified. The system's current state appears normal, and no other operations are in progress at the time of failure. This is the same state as the previous 100 or so successful swaps over the past few years.

Current status

I am seeking assistance to diagnose and resolve the root cause of the immediate swap failure, as the usual troubleshooting steps have not identified the issue, and the problem persists despite the cloud services being healthy and correctly configured. Deleting and Recreating the Deployment slot a couple of times has had no change. Both services perform as per normal, access the SQL database and log successfully to Microsoft Storage. The change between Live and Staging slots is an updated SQL query which does not fire until the new service is in the Production Slot and receiving messages from the live IP.

LogTag 0 Reputation points

2026-10-21T19:43:31.7566667+00:00
The capture shows the following sequence:

At 2026-10-21 19:25:38 UTC—22 October 2026, 08:25:38 NZDT—the portal submitted SetLoadBalancerFrontendPublicIpAddresses, exchanging the production and staging public IP references between the two load-balancer frontend configurations.

Azure accepted this request with HTTP 202.

Approximately 11 seconds later, the portal queried the URL returned in the Azure-AsyncOperation response header. That endpoint returned HTTP 200, with the following body:

{"status":"Failed","error":{"details":[]}}

The operation therefore reached a terminal Failed state, but Azure supplied no error code, message, or diagnostic details. The Activity Log shows only Started/Accepted entries and does not expose this final failure.

2 answers

Your answer

LogTag 0 Reputation points

2026-10-21T19:43:31.7566667+00:00

The capture shows the following sequence:

At 2026-10-21 19:25:38 UTC—22 October 2026, 08:25:38 NZDT—the portal submitted SetLoadBalancerFrontendPublicIpAddresses, exchanging the production and staging public IP references between the two load-balancer frontend configurations.

Azure accepted this request with HTTP 202.

Approximately 11 seconds later, the portal queried the URL returned in the Azure-AsyncOperation response header. That endpoint returned HTTP 200, with the following body:

{"status":"Failed","error":{"details":[]}}

The operation therefore reached a terminal Failed state, but Azure supplied no error code, message, or diagnostic details. The Activity Log shows only Started/Accepted entries and does not expose this final failure.

Answer 1

Hi logtag & thx for join me at Q&A platform,

fact that you've completed around 100 successful swaps with the same configuration, and now every attempt fails almost immediately, makes this worth investigating as a possible Azure control-plane or networking issue.

One important detail: Cloud Services (Extended Support) swaps are primarily networking operations. Azure switches the public IP associations between the deployments' load balancers. So the updated SQL query in ur worker role is unlikely to be responsible, especially if the failure happens before the swap actually starts.

You've already confirmed that both resources have provisioningState: Succeeded and their swappableCloudService references are correct. That's useful, but those checks alone don't guarantee the swap prerequisites are satisfied.

I'd verify that every role instance in both deployments is actually Running, not just that the cloud service resources show Succeeded. Also compare the public IP configurations on both sides. If one deployment uses a reserved/static IP, the other must meet the corresponding swap requirements. Guest OS updates, automatic healing, or an overlapping compute operation can also prevent a swap even when no user-initiated deployment is running.

The next thing I'd investigate is the actual ARM response behind the portal error. Open browser Developer Tools, reproduce the failure, and inspect the Network tab for the failed request. The swap uses the Microsoft.Network operation setLoadBalancerFrontendPublicIpAddresses, so a failure there could expose a more specific error code, HTTP status, or correlation ID than the generic portal message.

I wouldn't recommend repeatedly recreating the staging deployment at this point. You've already tried that without improvement, and it risks introducing more variables without identifying the failure.

If the request is rejected immediately and the backend response doesn't explain why, I'd open an Azure support case and ask for Cloud Services (Extended Support) and Azure Networking engineering to investigate the failed VIP swap operation. Provide the UTC timestamp, both cloud service resource IDs, associated load balancer and public IP resource IDs, and the request/correlation ID. Ask whether the failure is coming from swap validation, load balancer frontend reassignment, or a service-side regression.

One other thing worth planning for: Cloud Services (Extended Support) is scheduled for retirement on March 31, 2027. That doesn't explain this failure, and Microsoft should still investigate it, but I'd avoid investing too much in rebuilding the existing deployment architecture without considering the migration timeline.

Could u check whether the failed request appears under Microsoft.Network in the Activity Log, and whether its response contains an error code beyond the generic portal message? That would be the most useful next clue.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer

LogTag 0 Reputation points

2026-10-22T18:14:15.36+00:00

Hi Alex,

Thank you for the suggestions. I have now captured the portal network traffic and supplied the diagnostic extract, SwapFailure-2026-10-22.json, to Microsoft Support.

To answer your question, the Activity Log shows only Started/Accepted entries. The browser capture provides the final result:

At 2026-10-21 19:25:38 UTC, Azure accepted setLoadBalancerFrontendPublicIpAddresses with HTTP 202.

Approximately 11 seconds later, the URL returned in Azure-AsyncOperation responded with HTTP 200, containing:

{"status":"Failed","error":{"details":[]}}

No error code or message was returned. The request was therefore accepted and subsequently failed asynchronously.

We have also verified the role lifecycle state. Our roles have extensive startup, running and shutdown logging written to Azure Storage. Those logs confirm that the roles in both deployments had completed startup and were running during the attempted swaps. This verification is additional to the cloud service provisioning states.

Both cloud services show provisioningState: Succeeded, their swap-partner references are reciprocal, and both public IPs have been verified as static.

I have provided Support with the submission request ID 25dd842d-bd3c-4dcb-bcba-921ddc4768b0 and correlation ID 56b9158e-6cd2-4140-883a-74e3302d2572, and requested backend tracing with the appropriate Networking or Cloud Services team.

The cause remains unidentified. The next useful step appears to be determining which backend validation or execution step failed and why its error was not returned.

Kind regards, LogTag

Answer 2

The network capture provides an important distinction: the swap request was accepted with HTTP 202, but the asynchronous ARM operation later reached a terminal Failed state. HTTP 200 from the polling URL only means the poll itself succeeded; the body’s "status":"Failed" is the operation result.

Because the returned error contains no code, message or details, the service has not exposed a client-actionable cause. The portal’s generic error and the absence of a final failure in Activity Log are therefore consistent with the empty asynchronous-operation response.

Before escalating, verify and preserve:

Both Cloud Services (extended support) resources are in Succeeded state and no update, scaling or certificate operation is active.
Each resource’s swappableCloudService.id points to the other resource.
The two services still satisfy all documented swap prerequisites, including compatible location, networking and deployment configuration.
The production and staging frontend IP configurations, Public IP resources, SKU, zones, DNS labels and load-balancer settings have not drifted.
The full initial response headers, especially Azure-AsyncOperation, x-ms-request-id and x-ms-correlation-request-id.
The complete terminal polling response, resource IDs and UTC timestamp of the failure.

Given that the same pair previously completed many successful swaps, recreating slots did not help, and the control plane returned a terminal failure without an error code, repeatedly retrying is unlikely to reveal the root cause. This needs an Azure support investigation using the request/correlation IDs and backend operation logs.

The support case should specifically state that Microsoft.Compute/cloudServices/SetLoadBalancerFrontendPublicIpAddresses was accepted, then failed at the asynchronous-operation endpoint approximately 11 seconds later with:

{"status":"Failed","error":{"details":[]}}

Until Azure identifies the cause, avoid deleting or recreating the functioning production resource solely as a diagnostic. If an urgent release is required, use a separately validated deployment or traffic-management approach rather than relying on the failing swap.

References:

LogTag 0 Reputation points

2026-10-22T18:16:26.9133333+00:00

Thank you.

That distinction matches the capture: HTTP 200 means the status query succeeded; the response body explicitly reports that the swap failed, consistent with Microsoft’s asynchronous-operation documentation.

We have also checked the roles themselves. They have extensive startup, running and shutdown logging written to Azure Storage, and those logs confirm that the roles in both deployments had completed startup and were running during the attempted swaps. Both cloud services show Succeeded, their swap-partner references are reciprocal, and both public IPs are static.

I have already opened a Microsoft Support case and supplied the diagnostic extract, UTC timestamp, resource identifiers, request ID and correlation ID. The original HAR is available through the case’s secure upload facility if required.

One small correction for anyone following this thread: although the affected deployments are Microsoft.Compute/cloudServices resources, the swap REST endpoint is under Microsoft.Network:

POST /subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/{location}/setLoadBalancerFrontendPublicIpAddresses

This is the endpoint documented in Microsoft’s Cloud Services swap guidance.

The evidence confirms HTTP 202 acceptance followed by a terminal Failed result, without an error code, message or populated details. It does not yet establish whether the underlying cause is configuration validation, a conflicting operation or a service-side fault.

I have asked Support to identify the failing backend step, explain the missing diagnostic information and provide the corrective action. I will update this thread when Microsoft provides a substantive finding.