/api/devices/v2/deployments/device/deployments/next throws error

Hi, everyone! I hope everything goes well.

We have a Kubernetes cluster on AWS with Mender installed (recently upgraded to version 3.3.0 with the Helm package). It’s a Community Version and everything goes well, except for one thing that I cannot find in other topics.

There is a Yocto device (with mender version 3.3.1), that is connected to Mender Server (it works the terminal and, device information page), but when tries to use mender-client to check updates, the server throws the following error:

API-Gateway POD


Deployments POD

2023-01-16T19:39:42.885398665Z time="2023-01-16T19:39:42Z" level=info msg="404 74μs POST /api/devices/v2/deployments/device/deployments/next HTTP/1.1 - Go-http-client/1.1" byteswritten=30 device_id=39c03e78-6f4a-4cbd-a400-a8c21e64a1c3 file=middleware.go func="accesslog.(*AccessLogMiddleware).MiddlewareFunc.func1" line=71 method=POST path=/api/devices/v2/deployments/device/deployments/next plan=enterprise qs= request_id=b5151cdf-39f0-4e8d-ba3e-bafbbbe23d94 responsetime=7.4855e-05 status=404 ts="2023-01-16 19:39:42.885111128 +0000 UTC" type=http

Is like if the Mender server cannot found the path “/api/devices/v2/deployments/device/deployments/next”. In the other side, the API v! for deployments works well.

The followings are the pods installed with Helm:

NAMESPACE     NAME                                                   READY   STATUS    RESTARTS   AGE
default       api-gateway-657f58577b-w9cbr                           1/1     Running   0          4d1h
default       create-artifact-worker-6468c677bc-9w8mp                1/1     Running   0          4d1h
default       deployments-5847bf4d74-ldlx8                           1/1     Running   0          4d1h
default       device-auth-86f6dc6cb8-n7dww                           1/1     Running   0          4d1h
default       deviceconfig-64b7d578f9-rxbqs                          1/1     Running   0          4d1h
default       deviceconnect-587d54b6fd-j2hkl                         1/1     Running   0          4d1h
default       gui-8655495768-d5xsw                                   1/1     Running   0          4d1h
default       inventory-69f68bb849-pb96g                             1/1     Running   0          4d1h
default       iot-manager-6c5b485764-4tdrz                           1/1     Running   0          2d22h
default       nats-0                                                 3/3     Running   0          263d
default       nats-box-dd5fd77d5-pxzpp                               1/1     Running   0          4d1h
default       sonarqube-sonarqube-0                                  1/1     Running   0          4d1h
default       useradm-6895d8dcf4-4p7kg                               1/1     Running   0          4d1h
default       workflows-server-7fb47fd544-gkhg6                      1/1     Running   0          4d1h
default       workflows-worker-69c7f788f9-pn44j                      1/1     Running   0          4d1h

What could be happen?
The path ‘/api/devices/v2/deployments/device/deployments/next’ is only for subscriptions plans?

Thanks in advance for the help.

That’s correct, the v2 endpoint is only available in the Enterprise plan, and is used to implement dependency resolution for, among other things, binary delta updates. If it’s not available, the client will simply fall back to the v1 endpoint, so the message can just be ignored.

Thanks, it works! Just for anyone who asks the same question, we had a Cloudfront (CDN) between the device and the Kubernetes cluster (where resides Mender) and when devices tried to connect, the Cloudfront responses with a 5XX error, not a 404 error like the “mender-api-connect” pod. So the device, I think, don’t try to connect again to v1 API. Disabling the Cloudfront for Mender solved the issue.

Thanks for you help @kacf !