I have had issue with UTM connections on the water head so I wrote error detection software to notice the error and take recovery steps which worked perfectly as pins B-C would then detect. BUT
It would fail as FB would not know what tool was in the the UTM so I thought I would write some code to address that.
Here was my first attempt at the code. (Which I made a major error in)
tool = get_tool({name = "Watering Nozzle"})
toast(tool.id)
result = api({
method = "post",
url = "/api/device",
body = {
id = tool.id,
mounted_tool_id = 0
}
})
I ran it and got a horrendous-looking ‘stripy’ error web page, and now my FB is blank. It has forgotten everything.
I am not understanding how a single command like this could cause such damage. I accept I did not get my ID correct but it should not have caused such an impact it should have said sorry, that is not your ID and dropped the request. So the questions are.
What about the code above did the damage?
What can be done to check the parameters of calls to protect the coders?
Can I recover?
I am concerned that the custom code I wrote in LUA and all of the structures I built are lost.
Is there a backup/recovery facility that I could have performed to allow for a faster restore?
It is saying 0% step up and it has wiped my order ID and everything.
As I mentioned, unless you can remember what your Device Id was, FarmBot Inc. will have to help. If you do know your original Device Id, though, you should be able to use that dangerous code and replace tool.id with that Id value then run it ? (y.m.m.v., caveat, caveat …)
Device Id is like a Primary Key in FarmBot Inc. user accounts.
@mvillion Your device data is recoverable, and we’ll get it linked back to your user account.
The problem was you made a POST request to the /api/device endpoint. A POST request will create a new resource with the information provided in the body, in this case a new device. What you meant to do was make a PATCH request which would have updated your device with the information provided in the body, but you also would have not wanted to include id = tool.id because that would be setting your device id to the tool id.
A safer way to update your mounted_tool_id is with the update_device() helper:
We actually had two other people accidentally make this mistake in the last month (never before then had it happened) and we actually had a fix deployed to our staging server on Friday that removes the POST and DELETE /api/device` endpoints from the app entirely, to prevent mistakes like this from being possible. We unfortunately did not get the fix deployed to the production server before you made this mistake too, sorry!
But the good news is @Gabriel has recovered the information necessary to relink your user account to your original device, and we will get the fix deployed to the production server shortly after. We’ll also update the documentation a bit.
Glad to hear it is fixed up, and as of this morning the production web app no longer has POST or DELETE/api/device endpoints. I will be doing some additional testing today to see if there are any other ways in which someone might cause this issue and if I find anything we’ll patch it up.
