quark-bot-discord/gluon

Library for interacting with the Discord API, designed for Quark

gluon's Issues

does not reconnect to websocket when there is a "zombied" connection

see https://discord.com/developers/docs/topics/gateway#heartbeating-example-gateway-heartbeat-ack

need to disconnect and attempt to resume

add different run modes

"dev" - lots of logging
"prod" - no logging, process should continue running even if an error is encountered
"shadow" - runs in the background. everything happens as it usually would, except requests which cause an action are not made. needed for stress and stability testing

allow a/b testing

let shard ids be provided to the client, so the bot can give different responses for different servers

corrupted storage files from node-persist

should try to delete these files

add typings

to make it considerably easier to find your way around the lib

rolling/zero-downtime restarts

implement or allow a way to perform rolling/zero-downtime restarts

• perhaps could try restarting on the reconnect event? would avoid the issue of hitting the IDENTIFY limit
• ideally (and if we were to use the reconnect event) things should stay cached between restarts (and apparently "reloading" modules/files is not a great idea and can cause memory issues, so i would prefer to avoid that if possible)

request queues can get stuck

there is no recovery mechanism for if a queue gets stuck, requests just keep getting added indefinitely while no further requests are made

(JS-0111) Unnecessary `return await` function found

Description

Returning an awaited value (like with return await f()) has two problems: - It queues an extra microtask, blocking the callstack until return is executed.

Occurrences

There is 1 occurrence of this issue in the repository.

See all occurrences on DeepSource → app.deepsource.com/gh/quark-bot-discord/gluon/issue/JS-0111/occurrences/

ratelimits are occasionally exceeded with ~1 second or less remaining

during busy periods when lots of requests are trying to be processed, often at the same time, it is very common for ratelimits to be encountered with ~1 second or less of time until another request can be made, resulting in missed messages

complete documentation

select properties

provide option to include specific properties in cache

add toJSON and toString functions to all structures

and remove bundle functions, since they'll no longer be needed

guild create event

prevent guilds which have just recovered from being unavailable from being emitted again - should note if a guild is unavailable

improve permissions checking

cache role overrides too and calculate user permissions

selective caching

decide how it can be determined whether certain things should be cached for certain guilds

perhaps attach the gData structure to the guild, and determine from there?/more integration between the guild and gData structures

ratelimits

quark seems to get ratelimited very very occasionally, with <1 second left before another request can be made

likely due to network latency, and definitely something that should be accounted for

dynamically calculating this seems like the best way

check bucket ids are being handled correctly

clustering/process management

provide a quick and easy way of starting the bot on multiple processes, some of which may run slightly different code (for a/b testing)

rust re-write

rewrite gluon using rust?????

https://napi.rs ??????

need to handle reconnects and disconnections from the gateway

option to add more static data to storage rather than in memory

should ignore slash commands sent in dms