Bot gets locked in bad state if syncCommands throws error on startup

[JstnMcBrd]

Caused #61 .

The bot should be resilient to failures and always recover eventually. That is the purpose of the refresh() function that runs on a regular interval - to reset the bot state so issues never last for long.

However, this is not possible if the refresh() function is never called at the start. This can happen if the syncCommands() function throws an error before reaching refresh().
 

// src/events/ready.ts
export const ready = new EventHandler('ready')
	.setOnce(true)
	.setExecution(async (client) => {
		debug(`\tUser: ${client.user.username} (${client.user.id})`);
		await syncCommands(client);
		await refresh(client);
	});

Normally, if syncCommands() runs into an issue, it will exit the process entirely, forcing systemctl to restart the process. This is in line with the goal of never being locked in a bad state permanently - always recover.

But syncCommands() fetches commands from the Discord API.

// src/commands/index.ts
	const result = await client.application.commands.fetch();

If the API throws an error while fetching commands, this error will not be caught, and the ready event handler will simply fail before refresh() can be called, and the bot will be locked in a bad, uninitialized state. The whitelist will be empty, updating the whitelist will throw errors, the bot won't respond to any messages unless pinged, and the issue never auto-resolves because the refresh interval is not running.

This can only be fixed by manually restarting the process, which I don't know I need to do until someone notices the bot isn't working. This last time, it took over a month.

Moving refresh() to be called before syncCommands() may not be ideal, because refresh() responds to messages and syncCommands() may exit the process if commands are not in sync. We don't want to start responding to messages when the bot is going to terminate right after.