Open kurokobo opened 3 years ago
Thanks for the detailed report, I really appreciate it!
I wondered what the typical latency would look like for different spec machines. Tentatively I thought "any messages that are older than 5 seconds are stale enough that they shouldn't be processed", but you make an excellent point that on startup, the bot is under heavier load, and it makes sense that the latency should/would be longer. Really appreciate you providing concrete numbers.
I think I would probably opt for a higher default value (maybe 10 seconds), but additionally allow for it to be specified in ENV for flexibility. If even because, while 10+ seconds might be good enough in most situations, depending on the load of the system it might fluctuate and need to be more robust.
I think I'll spend a bit of time right now working on this, thanks for the report @kurokobo ! :)
(okay maybe not right now because I'm on vacation π . But it should be a pretty simple addition)
Thanks for your comment, I'm glad I could provide useful information.
Implicitly reading ENV from internal packages works but not very well-behaved / elegant, so I was thinking that the most straightforward way to use ENV is to create setter in internal/redis
, and call it from the MakeShardManager
(or AddHandler
).
Have a nice vacation!
Describe the bug
In a low-spec environment,
guildCreateHandlers
on AutoMuteUs side may not be triggered on startup if the bot is already a member of a guild.This happens because the
DiscordMessage
that Galactus pushed to Redis has been expired afterDiscordMessageTimeout
(5s) when the polling from AutoMuteUs has started.I had to rebuild Galactus with modifying that timeout to make AutoMuteUs works on some low-spec environment. From the log, it takes about 10 seconds in some case from DiscordMessage pushed by Galactus to poped by AutoMuteUs.
This problem seems to occur only immediately after startup, when multiple containers perform many processes at the same time. This doesN't occur after the state has stabilized after startup.
The following suggestions are possible, but please let me know if you have a preferred solution :thinking:
To Reproduce
Steps to reproduce the behavior:
docker-compose down -v
docker-compose up -d
Expected behavior
AutoMuteUs and Galactus handle guilds properly on its startup.
Screenshots
Once this issue occur, Galactus pushed the message to Redis, but not read from AutoMuteUs.
Version of bot & capture