ServiceFabricComposeDeploy: A communication error caused the operation to fail.

I’ve been using 2 test clusters with the preview release for service fabric 5.7, which have been working fine, but as 5.7 has been released now, I decided to go ahead and build a new cluster, using the same ARM template as before, just updating the version from preview to release.

This appeared to work fine, the cluster came online and I was able to browse the cluster explorer, and connect to the cluster via PowerShell. However, I then attempted to release a docker-compose application from VSTS onto the new cluster, which fails when calling “New-ServiceFabricComposeApplication” with the error “A communication error caused the operation to fail.”. I then went back to PowerShell and tried running the same commands myself, and the compose application gets created just fine without an error.

I have double checked the release configuration, and ensured all the settings are the same as the previous clusters, with the only difference being the host name for the client endpoint. I can see in the release logs that “Successfully connected to cluster.” is reported before attempting to create the application.

I have now re-run the deployment with “system.debug=true”, which gave the following stack trace: “System.Fabric.FabricException: A communication error caused the operation to fail. —> System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x80071BBC System.Fabric.Interop.NativeClient.IInternalFabricApplicationManagementClient.EndCreateComposeApplication(IFabricAsyncOperationContext context) at System.Fabric.Interop.Utility.<>c__DisplayClass20_0.<WrapNativeAsyncInvoke>b__0(IFabricAsyncOperationContext context) at System.Fabric.Interop.AsyncCallOutAdapter2`1.Finish(IFabricAsyncOperationContext context, Boolean expectedCompletedSynchronously) — End of inner exception stack trace —”

Any ideas what could be causing this exception from VSTS based release only?

[CodedBeard]

thanks @bishal-pdMSFT, to be honest, I’ve stopped using the hosted agents completely, As service fabric 6.0 has already been released before 5.7 got deployed, and we can’t be waiting 6 weeks between SF releases before we can actually use the release pipeline. We’ve also hugely benefited from using the private build agents due to caching, as we are migrating old systems into containers, which being based on server core are quite large. This was resulting in hosted builds taking almost 30 mins, most of which was just re-downloading the server core image every time, using private the builds went from 24 mins, to just over a min, so we will be sticking with this until the hosted build agent does a better job of caching container images.

[mikkelhegn]

No we should go ahead and do that.