Long delay for chesster replies in slack

[hopffgam]

It takes a long time (sometimes close to a minute) for chesster to reply to messages (scheduling messages, summons, other chesster commands).

Initial investigation showed that this is likely due to chesster hitting rate limits in the slack workspace.

[hopffgam]

I few thoughts for discussion:

• currently chesster downloads all slack users and all channels (without mpims) every 2 minutes. It is not proven but still reasonable to assume that these calls cause the timeouts.
• chesster needs the user data to be up to date for certain functionality (e.g. conversion into local time, apparently also to process the "link" command for a new user). We are not sure where else exactly chesster needs up-to-date slack user info.
• the users.list api endpoint seems to retrieve all users of the workspace. It does not allow filtering out e.g. deactivated users.

Essentially two approaches come to mind that could solve the issue:

1. Making the API call smaller by somehow getting rid of inactive users. I am not sure if it is even possible to delete users from a workspace. Deactivating them would not be sufficient as we cannot filter them out in the API call.
2. Reducing the frequency of the API call. As I am not sure at the moment for which functionality the updated user data is required, it is difficult to assess the consequences. The known situations: 2.a user switches local time zone. Chesster messages (pairing message and scheduling confirmation) would still assume the old time zone until data is updated. My personal opinion is that we can ignore this, as long as user data is updated at least daily. 2.b some slack user information is required to execute the "link" command. I haven't looked into that yet, but here a possibility would be to check chesster's db first and if that slack user is not known, query and store the data of that user specifically before continuing to execute the "link" command. 2.c For me it is unclear when exactly chesster needs to know channel information. One assumption is that it is required while executing the command to subscribe to all teams. If that is the case, one easy workaround is to run that command not immediately after team creation, but a few days later.

[hopffgam]

My personal preference would be to reduce the frequency of the updates from every 2 minutes to e.g. every hour as a short term fix to check if that even helps. Extending the "link" processing could be done in a second step, while we just tell players to try again in one hour if they are to quick.

[mathgeek]

Cutting that big fetch down to even a 5 minute schedule would reduce its load by 60% without much of an added delay. 10 minutes would reduce it by 80%. Might also be useful to add something that tracks how often each API call is invoked so there’s less guesswork involved.

[hopffgam]

Registered https://github.com/Lichess4545/Chesster/pull/379 as an initial attempt to see how much an increased interval helps

[hopffgam]

Seems like the PR solved the immediate problems.