Tasks fail with a "401 Unauthorized: [no body] (Unauthorized)" error in Aria Automation
search cancel

Tasks fail with a "401 Unauthorized: [no body] (Unauthorized)" error in Aria Automation

book

Article ID: 443033

calendar_today

Updated On:

Products

VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

  • In Aria Automation, tasks such as VM deployment fail with a "401 Unauthorized: [no body] (Unauthorized)" error.

  • The following error is recorded in the tango-blueprint-service-app.log:

    YYYY-mm-ddTHH:MM:SS.###Z ERROR tango-blueprint [host='tango-blueprint-service-app-##########-#####' thread='tasks-####' user='######' org='########-####-####-####-############' blueprint='########-####-####-####-############' project='########-####-####-####-############' deployment='########-####-####-####-############' request='########-####-####-####-############' flow='########-####-####-####-############' task='########-####-####-####-############' tile='########-####-####-####-############' resourceName='' operation='' trace='################################'] com.vmware.tango.blueprint.service.TileExecutionService - Tile execution failed with unhandled exception
    org.springframework.web.client.HttpClientErrorException$Unauthorized: 401 Unauthorized: [no body]
            at org.springframework.web.client.HttpClientErrorException.create(HttpClientErrorException.java:106) ~[spring-web-6.1.6.jar:6.1.6]
            at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:183) ~[spring-web-6.1.6.jar:6.1.6]
            at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:137) ~[spring-web-6.1.6.jar:6.1.6]
            at org.springframework.web.client.ResponseErrorHandler.handleError(ResponseErrorHandler.java:63) ~[spring-web-6.1.6.jar:6.1.6]
            at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:942) ~[spring-web-6.1.6.jar:6.1.6]
            at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:891) ~[spring-web-6.1.6.jar:6.1.6]
            at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:830) ~[spring-web-6.1.6.jar:6.1.6]
            at org.springframework.web.client.RestTemplate.postForLocation(RestTemplate.java:495) ~[spring-web-6.1.6.jar:6.1.6]
            at com.vmware.tango.blueprint.gateway.DeploymentRequestTrackerGateway.updateRequestTracker(DeploymentRequestTrackerGateway.java:57) ~[app.jar:?]
            at jdk.internal.reflect.GeneratedMethodAccessor545.invoke(Unknown Source) ~[?:?]
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
            at java.base/java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
            at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:354) ~[spring-aop-6.1.6.jar:6.1.6]
            at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:196) ~[spring-aop-6.1.6.jar:6.1.6]
            at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163) ~[spring-aop-6.1.6.jar:6.1.6]
            at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:768) ~[spring-aop-6.1.6.jar:6.1.6]
            at org.springframework.retry.interceptor.RetryOperationsInterceptor$1.doWithRetry(RetryOperationsInterceptor.java:102) ~[spring-retry-2.0.5.jar:?]
            at org.springframework.retry.support.RetryTemplate.doExecute(RetryTemplate.java:335) ~[spring-retry-2.0.5.jar:?]
            at org.springframework.retry.support.RetryTemplate.execute(RetryTemplate.java:211) ~[spring-retry-2.0.5.jar:?]
            at org.springframework.retry.interceptor.RetryOperationsInterceptor.invoke(RetryOperationsInterceptor.java:135) ~[spring-retry-2.0.5.jar:?]
            at org.springframework.retry.annotation.AnnotationAwareRetryOperationsInterceptor.invoke(AnnotationAwareRetryOperationsInterceptor.java:161) ~[spring-retry-2.0.5.jar:?]
            at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) ~[spring-aop-6.1.6.jar:6.1.6]
            at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:768) ~[spring-aop-6.1.6.jar:6.1.6]
            at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:720) ~[spring-aop-6.1.6.jar:6.1.6]
            at com.vmware.tango.blueprint.gateway.DeploymentRequestTrackerGateway$$SpringCGLIB$$0.updateRequestTracker(<generated>) ~[app.jar:?]
            at com.vmware.tango.blueprint.ebs.EbsTileService.processEbsCallback(EbsTileService.java:442) ~[app.jar:?]
            at com.vmware.tango.blueprint.ebs.EbsTileService.execute(EbsTileService.java:100) ~[app.jar:?]
            at com.vmware.tango.blueprint.service.TileExecutionService.execute(TileExecutionService.java:745) ~[app.jar:?]
            at com.vmware.tango.blueprint.service.TileExecutionService.lambda$createTileRunnable$18(TileExecutionService.java:1159) ~[app.jar:?]
            at com.vmware.tango.blueprint.service.BlueprintSwitchUserService.withAuthentication(BlueprintSwitchUserService.java:51) ~[app.jar:?]
            at com.vmware.tango.blueprint.service.BlueprintSwitchUserService.withCspOauthToken(BlueprintSwitchUserService.java:72) ~[app.jar:?]
            at com.vmware.tango.blueprint.service.TileExecutionService.withAuthContext(TileExecutionService.java:1212) ~[app.jar:?]
            at com.vmware.tango.blueprint.service.TileExecutionService.lambda$createTileRunnable$19(TileExecutionService.java:1160) ~[app.jar:?]
            at com.vmware.tango.blueprint.service.TileExecutionService.withTraceContext(TileExecutionService.java:1183) ~[app.jar:?]
            at com.vmware.tango.blueprint.service.TileExecutionService.lambda$createTileRunnable$20(TileExecutionService.java:1161) ~[app.jar:?]
            at com.vmware.tango.blueprint.service.TileExecutionService.lambda$createTileRunnable$21(TileExecutionService.java:1164) ~[app.jar:?]
            at com.vmware.cmf.observation.tracing.RootTraceTaskDecorator.executeRunnable(RootTraceTaskDecorator.java:80) ~[spring-observation-#.#.5.53.2.jar:#.#.5.53.2]
            at com.vmware.cmf.observation.tracing.RootTraceTaskDecorator.lambda$decorate$0(RootTraceTaskDecorator.java:58) ~[spring-observation-#.#.5.53.2.jar:#.#.5.53.2]
            at com.vmware.tango.blueprint.TangoBlueprintApplication$RequestTaskDecorator.lambda$decorate$0(TangoBlueprintApplication.java:298) ~[app.jar:?]
            at io.micrometer.observation.Observation.observe(Observation.java:499) ~[micrometer-observation-1.12.5.jar:1.12.5]
            at com.vmware.cmf.observation.propagation.ObservationTaskDecorator.lambda$decorate$0(ObservationTaskDecorator.java:46) ~[spring-observation-#.#.5.53.2.jar:#.#.5.53.2]
            at io.micrometer.context.ContextSnapshot.lambda$wrap$0(ContextSnapshot.java:91) ~[context-propagation-1.1.1.jar:1.1.1]
            at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
            at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
            at java.base/java.lang.Thread.run(Thread.java:840) [?:?]


  • The following warning is recorded in the catalog-service-app.log:

    YYYY-mm-ddTHH:MM:SS.###Z WARN catalog-service-app [host='catalog-service-app-##########-#####' thread='http-nio-8000-exec-####' user='' org='' trace='=################################'] c.v.s.csp.auth.jwt.CmfJwtDecoderAdaptor - Failed to decode token. An error occurred while attempting to decode the Jwt: Jwt expired at YYYY-mm-ddTHH:MM:SS.##Z

Environment

Aria Automation 8.18.x

Cause

This issue occurs when there is a time drift between VMware Identity Manager (vIDM) and Aria Automation.
As a result, an expired cached token is inadvertently used during task execution.

Resolution

Investigate and correct the underlying cause of the time desynchronization between the components.

Additional Information

One known trigger for this condition occurs in environments upgraded to Aria Automation 8.18, where the systemd-timesyncd service may fail to start automatically after the upgrade process.

For detailed symptoms and resolution steps regarding the service startup issue, please refer to the following KB article:
https://knowledge.broadcom.com/external/article/442714