| Commit message (Collapse) | Author | Lines |
|
|
|
This is a prequel to adding a calendar command. To avoid re-querying
the branding repo on command invocation, event information will be
cached whenever we make requests. The command can then simply get an
up-to-date event schedule from the cache, with the option of forcing
an update via the 'populate_cache_events' function.
Since we cannot easily serialize entire 'Event' instances, we simply
store what's needed - the event name, and its duration.
The author has verified that the cache maintains order; in this case
chronological order based on event start date.
|
|
|
|
|
|
|
|
|
|
Sync make also be invoked with a command; avoid logic duplication.
|
|
|
|
This adds the core logic of branding management. In comparison with the
previous version, we now maintain all state in Redis, which allows the
bot to seamlessly restart without losing any information.
The 'send_info_embed' function is intentionally implemented with the
consideration of allowing users to invoke it on-demand. It always
reads information from the cache, even if the caller could pass
a 'MetaFile' instance. So while this may look needlessly indirect
right now, it should begin to make sense once the command API
is implemented.
|
|
|
|
|
|
|
|
|
|
This allows us to add a neat string representation.
|
|
These methods form the API to the repository abstraction.
|
|
|
|
|
|
Constants will only be used in one place and there's not enough of them
to warrant a separate module.
|
|
|
|
Since we're planning substantial changes, it will be easier to build
from scratch.
|
|
|
|
|
|
Bug caused by an outdated function signature in a previous commit in the #1402 PR
|
|
|
|
|
|
|
|
|
|
|
|
The idea to ignore alerts on fake redis didn't solve the problem completely, because sometimes you'll just develop with a real redis. It also didn't solve the ping we would get on first start up.
After looking into it there seems like there's no actual reason to alert on key errors, as they should only happen if the cache gets wiped for some reason, which shouldn't happen, but in which case we have bigger issues. Alerts are therefore limited to connection errors raised by redis.
This additionally handles only redis errors when writing to it as well. If any other error is raised it is ok for the function to stop at that point, as all variables have already been set. The only thing which doesn't get executed is the confirmation message and logging, the lack of which is an exception message in itself.
|
|
|
|
|
|
|
|
|