Keeping idling Tor Browser open for few hours leaves RoboSats in inconsistent state

[kristapsk]

Had previously successfully created order, later cancelled it (because going to sleep) and kept it in "order have been cancelled" page or whatever was exact message directly after cancelling order. Then Tor Browser was idling for around 8 hours. When trying to create order again, it seems to be in inconsistent stage, where it allows to fill in form (and remembers old values), after pressing "Create order" even gives "Store your robot token" backup dialog (with correct backup string), but afterwards gives error "Woops! It seems you do not have a robot avatar".

Looked at Developer Tools, http://robosats6tkf3eva7x2voqso3a5wcorsnw34jveyxfqi2fu7oyheasid.onion/api/make/ request responds with "400 Bad Request" and that error message.

Restarting Tor Browser solved the problem.

[Reckless-Satoshi]

Thanks for reporting!

Explanation of what is probably happening: Seems related to a mix of new and old features. Your robot died during the night (inactive robots are deleted at midnight to avoid growing the app size of the coordinator), yet the frontend had not been refreshed (so it believed to be logged in... but it was not! The session and "user" had been deleted!). Re entering the token solves the issue as you are effectively creating again the same identity.

You got a "Woops! it seems you do not have a robot avatar" which is a literal error message sent from the backend as a reply to a request to the /api/make without a robot (user) in the request.

A robot that has any valuable state in the backend (an active order, a past completed order or rewards) would have survived the midnight purge.

Fix I guess the fix must go on the line of implementing a check for "is this robot still valid?" that runs every X hours or after midnight on the client too. It certainly is an edge case but we will see it happen more often now that Tokens are remembered in the Android app.

Another fix is for the coordinator to not purge robots. But that increases the cost of running a coordinator and ideally we want to move on the opposite direction: stateless backends, store nothing at all.