|  | Commit message (Collapse) | Author | Age | Lines | 
|---|
| ... |  | 
| | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | This contains the main logic for handling reactions and glues all the
helpers together.
Unfortunately, gracefully handling everything that can go wrong in
the process requires quite a lot of code ~ but, at least to me, it
seems like this all should now be fairly safe.
The idea to await the message delete event before releasing the lock
was conceived by Ves, while Mark helped me refine it.
Co-authored-by: Sebastiaan Zeeff <[email protected]>
Co-authored-by: MarkKoz <[email protected]> | 
| | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | See docstring! | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | See docstring. The exception log is DEBUG level as failure does not
necessarily indicate that we have done something wrong. We rely on
the API to tell us that the message no longer exists in situations
where we have 2 coroutines racing to archive the same message. | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | The crawler now avoids making API calls for messages which:
  * Are not incidents
  * Already have all signals
As a result, we can sleep only after making actual calls. This speeds
up the task completion considerable, while also making it lighter
on the API. Victory! | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | Looks like we'll need quite a few helpers, and I think it's cleaner
to keep them at module level.
It helps avoid the question of: what do I do if a staticmethod
depends on another staticmethod? | 
| | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | The code is now basically self-documenting, the docstring is no
longer necessary.
The ultimate goal is to allow `crawl_incidents` to be more smart
about which messages need to be passed to `add_signals`, so that
it doesn't need to sleep after each message. | 
| | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | This is now necessary as we call the listener ourselves from the
crawl task. An already existing, pinned message, can be received. | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | See docstring for further information. This will run on start-up
to retroactively add missing emoji.
Ratelimit-wise this should be fine, as there should never be too
many missing emoji. | 
| | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | Looks like it can be static, at least for now. | 
| | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | These serve as whitelists, i.e. any reaction using an emoji not
explicitly allowed, or from a user not specifically allowed,
will be rejected. Such reactions will be removed by the bot. | 
| | |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ |  | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | |\ \ \ \  
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | | role-reminders | 
| | | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | | Co-authored-by: Mark <[email protected]> | 
| | | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | | This reverts commit 776b4379c478284803a4a526b5f14fe63d8e7c01.
This is already being fixed in #835, and therefore is no longer
required. | 
| | | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | | This also accounts for the author passing themselves to mention, and
therefore avoids the user from being told they're not allowed to mention
themselves even though they could. | 
| | | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | | The reminder expiration returnedfrom the API call is also now parsed
again even when the edit is to the duration since it does not matter and
trying to keep it DRY while still doing that check is a pain. | 
| | | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | |/ / / / |  | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | The function `_delete_reminder` was called twice, once in
`schedule_reminder`, which calls `send_reminder`, then another in
`send_reminder` itself. This led to a 404 response from the site api, as
the reminder was already deleted the first time.
Fixes BOT-6W | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | Kind of redundant since it's only used by two tests. | 
| | | | | | | | | | | | | | | | | | |  | 
| | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | stop needs to be called on the patcher, not the mock. Furthermore,
using addCleanup is safer than tearDown because the latter may not be
called if an exception is raised in setUp. |