Looks like it’s reasonably easy for any bot to step on itself if for whatever accident there are two copies of bot running.
Can we have a ctrl.exlusiveLock/Unlock that would reject any commands if the ctrl is already locked by any other connection? the unlock must be dropped automatically if the connection dies.
It may sound like a fairly easy request. Afraid it is not 
The service(s) has no knowledge about specific connections.
All connections are handled by the gateway(s). And for requests over HTTP, the connections are highly temporary (only exists during the duration of the HTTP request).
This request would probably require new additions to the RES protocol and to Resgate. The feature to track connections on Resgate has been requested before, but not yet implemented.
So there’s absolutely no state tracking? If I auth something on one connection all the other ones are authed as well? (thinking if this could be worked around as a token you need to auth against).
What about using the ability to transition the character to awake as the lock? Is there a reasonable way to have the bot script check whether the character is already in the “awake” state" and exit early if the character isn’t asleep at the outset?
Oh, that’s actually a great point. I think it’s very doable.
The services tracks no connection/client state what so ever. This is what makes it easy to update/restart services without disruption, and opens up for full horizontal scaling (maybe not for Wolfery, due to the service architecture I choose. But for other Resgate based projects, it can be used to scale near endlessly).
The gateway, however, keeps state of all connections. It stores things like tokens (retrieved after a successful auth call for that connection), and which resources are currently being subscribed by each connection. However, once a connection is closed, the gateway will instantly drop all state for that connection.
If you do an auth call, it is only that single connection that gets authenticated.
For HTTP requests, the auth call is made transparently by Resgate, using the HTTP headers.
If you just want a single copy of a daemon running or something, you could manage that on the local system, presumably?
Just use a lock file with a pid for the KISS principle (kill(pid, 0) to check to see if the process died); or, another strategy might be to try to grab an exclusive lock on a lockfile, and if that succeeds, leave the file open and go to town. When the daemon dies, the file closes, and the lock goes away. If the daemon isn’t able to get a lock, assume another copy is running.
I’m jumping to some potentially POSIX-flavored conclusions here and going from admittedly dim memory, so there’s no warranty included with these suggestions. 
Yeah… the only issue is that the agent runs on GH actions, and if you have two PRs following one another all hell breaks loose.