| Commit message (Collapse) | Author | Lines |
|
If the lock causes the function to abort, a new channel shouldn't be
made available. However, the only way to know it's aborted from the
outside would be through a return value or global variable. Neither seem
as nice as just just using `create_task` within the lock to avoid
having `move_to_available` hold the lock.
|
|
Normally exceptions are only logged when tasks are garbage collected.
This wrapper will allow them to be logged immediately through a done
callback. This is similar to how the Scheduler logs errors.
|
|
The race condition is when a user claims a channel while their other
channel is being unclaimed. Specifically, it's while their cooldown is
being removed.
The lock ensures that either the cooldown will be re-applied after it's
removed or that it won't be removed since `unclaim_channel` will see the
user has another claimed channel.
|
|
It's been determined that asyncio.Lock is safe to use in such manner.
Therefore, replace LockGuard entirely with asyncio.Lock.
|
|
Narrow the scope of `move_to_dormant` to just moving the channel.
Following the design of `claim_channel`, make `unclaim_channel` handle
cooldowns and unpinning.
|
|
|
|
Move significant code related to stats to a separate module.
|
|
|
|
It's conceivable for a user to be able to quickly send a message in all
available channels before the code has a chance to add the cooldown
role.
Place a lock on the author to prevent the claim code from running
multiple times for the same user.
|
|
It feels safer to do this since the init task moves channels to
different categories and the listeners check if channels are in certain
categories.
|
|
Use the `lock_arg` decorator to keep a separate lock for each channel
rather than a single lock used by all messages. Separate the core logic
in `on_message` into a separate function to facilitate the use of
`lock_arg` - not everything in `on_message` needs to be under the lock.
|
|
|
|
Co-authored-by: Dennis Pham <[email protected]>
|
|
Co-authored-by: Dennis Pham <[email protected]>
|
|
|
|
Related to #1342.
|
|
|
|
Co-authored-by: Xithrius <[email protected]>
|
|
|
|
|
|
Previously, `!user` said if the user is "Pending", whereas "Verified" is
the boolean opposite.
|
|
This was a logic error. This functionality is unfortunately difficult to test outside of production.
|
|
|
|
|
|
|
|
Renamed method; if not `user.pending`, adds and immediately removes an arbitrary role (namely the Announcements role), which verifies the user.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Forgot to remove these when removing `loop_is_running` in a previous
commit.
|
|
The client is already instantiated in a coroutine and aiohttp won't
complain. Therefore, scheduling a task to create the session is
redundant.
|
|
Supporting the function means supporting re-use of a closed Bot.
However, this functionality is not relied upon by anything nor will it
ever be in the foreseeable future.
Support of it required scheduling any needed startup coroutines as
tasks. This made augmenting the Bot clunky and didn't make it easy to
wait for startup coroutines to complete before logging in.
|
|
|
|
Making the class-reusable is not worth the added complexity.
|