How do I mitigate/resolve an INCONSISTENT device state

I have added a new Jetson AGX device to my hosted Mender. I don’t have any previous full file system artifacts of the device, I just went ahead and started configuring the device, primarily doing update module work and it just happened to go into this inconsistent state.

I have found numerous threads around this issue and they all seem to point back to the same “…deploy the last full image update artifact to the device to clean it up.” solution - unfortunately we don’t have this right now for various reasons, and there have been no previous deployments.

Are there any other remedies that I can try to rectify this issue? It’s also worth mentioning I was receiving “429 Too Many Requests” errors when attempting to do the same deployment again - I can only assume it’s down to the fact it’s continuously attempting to find an artifact to rollback to and it can’t be found because there isn’t one.

Thanks in advance.

UPDATE: We’re currently running on a free tier account to prove if Mender can work for us. I’ve just found that the reason it’s throwing a 429 is because the polling on the other test Jetson device and the one I’m working on is set to 5 seconds whilst also attempting deployments. I upped the poll time considerably on the Jetson not in development and upped the poll time to double on the Jetson I’m deploying and developing on - /etc/mender/mender.conf.

I restarted the mender client and it fired a 429 (which now tells me it’s rate limiting at a service level rather from a deployment/API level) - I waited 5-10 minutes, attempted the restart again and it started successfully. When I attempted a deployment it went through successfully.

In my opinion this isn’t very well documented - if at all for free tier users. I have found some documentation relating to rate limiting but only from a configuration perspective on the enterprise tier.

Hope this helps someone else with the same issue.