Device not decommissioned when all auth sets are dismissed

General Discussions
1

I entered a strange state while experimenting with preauthorization and was hoping someone could confirm if this is intended behavior.

I had an already authorized device with one auth set and instead of decommissioning the device, I dismissed the one auth set which then removed the device from the device list. I just assumed that the device was automatically decommissioned since there were no more auth sets left, but I was wrong…

When I tried to preauthorize the device again I kept getting errors saying the device was already authed (409 return codes) but I couldn’t find any mention of it anywhere. Finally I thought maybe I should do an auth request to get it to pending state, accept it, then explicitly decommission it which did the trick and actually removed all device data from the server.

If this isn’t a bug, then at least there should be some reference to a device that still is tracked on the server even if it has no auth sets anymore.

1 Like
2

Which server version are you running?

I know that there have been some bugs which might be related to this. @mzedel @tranchitella probably know more.

3

I’m using the hosted version, so I assume the latest?

If I get into a buggy state, what’s the best way to get things back to normal? Through the REST API?

4

Also related question, I somehow got some of my pending devices into a status of Noauth and whenever I click on the device I get an immediate error on the server. So, I can’t remove them. I’m going to see if I can remove with the API but any advice?

5

Answering my own question. I was able to see the noauth devices using the REST API and removed them that way.

Last remaining weird thing is I’m seeing an incorrect number of deployments in the dashboard tab. It shows 107 active and pending deployments but in reality there are zero of each.

6

Hello @msaenger,
the noauth state is rather interesting and I would agree that this should be easier to see/ solve… we’ll find a way to surface these or prevent them from being possible altogether. Thanks to your description that should be easily reproducible and thus easier to fix :).

The faulty deployment number is unfortunately an unwanted side effect of our latest rollout and the corresponding fix should land in production shortly.

7

Thanks for the update, @mzedel!

I’m not quite sure exactly how I got into a noauth state, but I was doing a lot of experimenting with preauthorization and using different types of identity data. One further piece of information for you if it helps: the server showed two noauth devices but when I went to list the devices with the API there were 4 or 5 in that state.