Possible to prevent multiple instances of bot from running at the same time?

[casey]

Is it possible to prevent multiple instances of a bot from running at the same time?

I looked through the docs, but wasn't able to figure out how.

[arqunis]

Could you explain what you mean by "running at the same time"? Do you mean two Clients instances in the same process, or two Clients in different processes? If it's the latter, there's nothing that the library can do about that. Discord allows many connections to the same account, so this is legal. If it's the former, the only way for that to occur is if you started two Clients in different threads, but other than that, the library still has no mechanisms to prevent this. In fact, the library is designed to allow multiple Clients to run in parallel in the same process.

If you what you want to avoid is the latter situation, you could employ a file lock. Before you create a Client, you check for the existence of a file. If it doesn't exist, you create one and start the client, and upon shutting down your bot, you remove the file. If it does exist, you exit out of the program. This will ensure only one Client in a single process can be run.

[casey]

I'd like to prevent multiple instances of a bot binary from connecting to the same account, even if they're started on different machines. A file lock wouldn't work, because I might have the binary running on two different machines, or under two different accounts.

This is desirable because if I accidentally start two instances, the bot responds to actions twice. Ideally, everything the bot does will be idempotent, but I'd like to avoid making that a hard requirement.

Is there some way of getting the number of currently connected clients to the account? If I could do that, then perhaps I could implement this myself.

[vicky5124]

https://serenity-rs.github.io/serenity/current/serenity/model/gateway/struct.SessionStartLimit.html You could probably be clever with this, and close the session if the number of allowed sessions is below the max-1

[casey]

@nitsuga5124 That's a good thought! Although, if the ratelimit period is 10 minutes (I'm not sure, but that's what I read in the API docs) then that might not work if an instance is launched, killed, and then relaunched within a 10 minute window.

[vicky5124]

What would be ideal is for serenity to support the gateway return value that tells you how many connections you have right now; i have seen it on other libraries such as python's hikari, that log how many sessions you have open of the bot.

[casey]

That would be awesome. Is that return value mentioned in the docs? I couldn't find it in the gateway docs.

[kangalio]

i have seen it on other libraries such as python's hikari, that log how many sessions you have open of the bot.

@vicky5124 Where in hikari have you seen that? I can't find it (neither in the official Discord docs)

[vicky5124]

https://github.com/hikari-py/hikari/blob/b33a5c7b392d9de0afdeb271940c81865aaf252f/hikari/impl/bot.py#L1040 @kangalioo

[kangalio]

I see. But that count of open sessions resets after reset_after milliseconds. In Discord's example payload, that's 14400000 which is 4 hours. So, this approach can only detect multiple sessions if they were started within 4 hours.

I'm afraid it is impossible to do what OP is asking for (well; apart from the obvious solution of tracking open sessions yourself on some web service. But that's independent from the Discord API and serenity)

[vicky5124]

Tracking within 4 hours is still nice to have, usually when multiple sessions are an issue is when you are testing the bot, and previous sessions are left open by accident, not in production.

[kangalio]

Serenity already supports the endpoint in question (link) so I tested it. That tracker of sessions in the last 4 hours only tracks the number of sessions started, not currently active. So we're back to square one. I'll close this issue unless someone has a new idea how this feature request might be possible