aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeLines
...
| | | | | | | * | | | | | | Move GitHub API key to better locationGravatar ks1292020-11-17-13/+5
| | | | | | | | | | | | | |
| | | | | | | * | | | | | | Port branding management to this bot from SeasonalBotGravatar ks1292020-11-17-0/+569
| | | | | | | | | | | | | |
| | | | | | | * | | | | | | Handle branding error in error handlerGravatar ks1292020-11-17-2/+6
| | | | | | | | | | | | | |
| | | | | | | * | | | | | | Create mock_in_debug decorator for brandingGravatar ks1292020-11-17-1/+22
| | | | | | | | | | | | | |
| | | | | | | * | | | | | | Add required colors and emoji for branding managementGravatar ks1292020-11-17-0/+12
| | | | | | | | | | | | | |
| | | | | | | * | | | | | | Create AssetType enumGravatar ks1292020-11-16-0/+11
| | | | | | | | | | | | | |
| | | | | | | * | | | | | | Add arrow dependency for brandingGravatar ks1292020-11-16-1/+10
| | | | | | | | | | | | | |
| | | | | | | * | | | | | | Create config for tokens and add GitHub tokenGravatar ks1292020-11-16-0/+10
| | | | | | | | | | | | | |
| | | | | | | * | | | | | | Add basic branding configurationGravatar ks1292020-11-16-0/+10
| | | | | | | | | | | | | |
| | | | | | | * | | | | | | Port seasons from SeasonalBot to hereGravatar ks1292020-11-16-0/+181
| | | | | | | | | | | | | |
| | | | | | | * | | | | | | Add BrandingError to errorsGravatar ks1292020-11-16-0/+6
| | | | | | | | | | | | | |
| | | | | | | * | | | | | | Add months Enum to constantsGravatar ks1292020-11-16-1/+19
| | | | | | | | | | | | | |
| | | | | | | | | | * | | | Move not allowed to run message to constant and match comment with codeGravatar ks1292020-12-02-4/+6
| | | | | | | | | | | | | |
| | | | | | | | | | * | | | Don't log CommandError, handle it as check failGravatar ks1292020-11-21-2/+2
| | | | | | | | | | | | | |
| | | | | | | | | | * | | | Fix import order of help command fileGravatar ks1292020-11-07-1/+1
| | | | | | | | | | | | | |
| | | | | | | | | | * | | | Catch CommandError for help command can_run awaitGravatar ks1292020-11-07-5/+9
| | | | | | | | | | | | | |
| | | | | | | | | | * | | | Merge branch 'master' into help-disabled-commandGravatar ks1292020-11-07-1496/+2971
| | | | | | | | | | |\ \ \ \
| | | | | | | | | | * | | | | Help: Show different message for case when command is disabledGravatar ks1292020-09-28-2/+5
| | | | | | | | | | | | | | |
| | | | | | | | | | * | | | | Help: Add handling of disabled commands to avoid DisabledCommand errorGravatar ks1292020-09-27-1/+1
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | * Set asyncio logger level to INFOGravatar MarkKoz2021-01-04-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If asyncio's debug mode is enabled, the asyncio logger's level gets set to DEBUG. While other features of the debug mode are useful, the DEBUG log level spams generally irrelevant stuff.
| | | | | | | | | | | | | | * HelpChannels: fix unclaim exiting too early if claimant is NoneGravatar MarkKoz2021-01-04-4/+2
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | * HelpChannels: fix manual use of lock decoratorGravatar MarkKoz2021-01-04-3/+3
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | * HelpChannels: fix race condition when unclaiming a channelGravatar MarkKoz2021-01-04-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Place a channel-specific lock on `unclaim_channel`. If both the dormant task and the command simultaneously unclaim a channel, one of them will silently be aborted. Fix #1341
| | | | | | | | | | | | | | * HelpChannels: change caller str parameter to a boolGravatar MarkKoz2021-01-04-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Booleans are less error-prone than strings.
| | | | | | | | | | | | | | * HelpChannels: unschedule the dormant task in unclaim_channelGravatar MarkKoz2021-01-04-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ensure the cancellation will be under the lock once the lock is added.
| | | | | | | | | | | | | | * HelpChannels: clarify close command docstringGravatar MarkKoz2021-01-04-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Referencing internal functions in public-facing documentation is not helpful to users.
| | | | | | | | | | | | | | * HelpChannels: refactor the close command checkGravatar MarkKoz2021-01-04-10/+10
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | * HelpChannels: make a channel available within the lockGravatar MarkKoz2021-01-04-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| | | | | | | | | | | | | | * Add asyncio.create_task wrapper which logs exceptionsGravatar MarkKoz2021-01-04-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| | | | | | | | | | | | | | * HelpChannels: fix race condition between claiming and unclaimingGravatar MarkKoz2021-01-04-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| | | | | | | | | | | | | | * Lock: support waiting until a lock is availableGravatar MarkKoz2021-01-04-37/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's been determined that asyncio.Lock is safe to use in such manner. Therefore, replace LockGuard entirely with asyncio.Lock.
| | | | | | | | | | | | | | * HelpChannels: refactor channel unclaimingGravatar MarkKoz2021-01-04-20/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| | | | | | | | | | | | | | * HelpChannels: remove obsolete channel position trace logGravatar MarkKoz2021-01-04-1/+0
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | * HelpChannels: refactor stat trackingGravatar MarkKoz2021-01-04-27/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move significant code related to stats to a separate module.
| | | | | | | | | | | | | | * HelpChannels: move function to the channel moduleGravatar MarkKoz2021-01-04-42/+45
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | * HelpChannels: prevent user from claiming multiple channels quicklyGravatar MarkKoz2021-01-04-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| | | | | | | | | | | | | | * HelpChannels: await init task at the start of event listenersGravatar MarkKoz2021-01-04-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| | | | | | | | | | | | | | * HelpChannels: use a more accurate lock for messagesGravatar MarkKoz2021-01-04-47/+35
| | | | | | | | | | |_|_|_|/ | | | | | | | | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | | | | | | | | | | Fix issues with multiple gets being suspended when a refresh startsGravatar Numerlor2021-01-22-6/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With a normal event, if multiple gets were suspended and a refresh started, we'd continue the refresh after the first get finished and set the event which would be the same behaviour as the one it tried to fix. This is avoided by using a counter that's incremented every time a context manager is entered around an event and only setting the event when that counter reaches a zero after everything exited the context mgr
* | | | | | | | | | | | | | Use inspect.unwrap instead of manually unwrappingGravatar Numerlor2021-01-21-3/+1
| | | | | | | | | | | | | |
* | | | | | | | | | | | | | Use a defaultdict for item futuresGravatar Numerlor2021-01-15-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To be able to set the attribute at the start of the coro we need to be able to access the item's future before we know about all the other items. This also saves us from having to add them all as the queue parser or get_markdown will create the futures for us dynamically
* | | | | | | | | | | | | | Prevent an inventory refresh while waiting for item cacheGravatar Numerlor2021-01-14-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If an inventory refresh was started while the symbol embed coroutine was suspended, it could cause the parser to try to fetch a non existent future if the markdown was requested after it was cleared but before new inventories were loaded in.
* | | | | | | | | | | | | | Raise an error or log a warning if there's a global name conflictGravatar Numerlor2021-01-14-5/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When wrapper uses a global name, which conflicts with a global name from wrapped's module that wrapped uses for its annotations, we run into a situation that can't be solved without changing one of the names, so an error is raised to give this clearer meaning. The check may be erroneous in some edge cases or the objects the conflicting names refer to can be functionally identical, so the error can be turned into a logged warning.
* | | | | | | | | | | | | | Ensure footer is actually max 100 charsGravatar Numerlor2021-01-14-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Shortening the renamed symbols string to 100 chars is not accurate as the footer also contains a string before that, subtracting its length fixes this.
* | | | | | | | | | | | | | Set the user_requested attribute at the start of the coroutineGravatar Numerlor2021-01-14-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A context switch may occur when we're waiting for the web page response, during which a clear could be triggered. If the event is not set before that we could end up with the dictionary changing sizes, or if a copy was made, a future that'd never finish as it'd be cleared from the queue and the futures dict
* | | | | | | | | | | | | | Reuse the redis key instead of creating a new string for the expires setGravatar Numerlor2021-01-14-2/+2
| | | | | | | | | | | | | |
* | | | | | | | | | | | | | Change typehint name casing to PascalCaseGravatar Numerlor2021-01-14-8/+9
| | | | | | | | | | | | | |
* | | | | | | | | | | | | | Keep trakck of the init task and cancel it when the cog is unloadedGravatar Numerlor2021-01-14-1/+2
| | | | | | | | | | | | | |
* | | | | | | | | | | | | | Simplify control flowGravatar Numerlor2021-01-14-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Co-authored-by: MarkKoz <[email protected]>
* | | | | | | | | | | | | | Use different task ids for every inventory reschedule attemptsGravatar Numerlor2021-01-14-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The scheduler can't keep track of multiple tasks with the same id, and rescheduling the update task using the same id within an already scheduled update task caused the new task to get ignored as the old task only got deleted from the scheduler after it was finished