This PR closes #105
This PR fixes exceptions caused by changing a collection's contents
while it is being enumerated. This can often happen with Guild- and
MemberDatas. By using `ToArray()` on these global collections and using
it in the `foreach` loop, we create a new copy of the collection,
preventing any modification to it.
While this does introduce a lot of memory allocations, there is no
fixing that. Usually, the fix to these exceptions would be to convert
the `foreach` to a reverse-`for`. However, because indices cannot be
used on these collections, that is not possible.
Signed-off-by: Octol1ttle <l1ttleofficial@outlook.com>
This PR closes #85.
This PR fixes many issues related to scheduled events. Most importantly,
scheduled events that are no longer present in the guild, but still have
data related to them, won't be left rotting.
This requires deletion of `ScheduledEvents.json` files in all guilds.
Maybe I'll start writing datafixers one day...
Signed-off-by: Octol1ttle <l1ttleofficial@outlook.com>
This PR fixes EventEarlyNotification timestamp not displaying correctly
and also has some other changes:
- Add xmldocs for `/settingslist`'s `page` option in
SettingsCommandGroup.cs
- Add option description for `index` for `/delreminder`
- Some corrections of grammatical errors in Messages.tt-ru.resx
- Fix `ArgumentOutOfRangeException` in `/settingslist` that appears if
the user uses a negative integer in `page`
---------
Signed-off-by: Macintosh II <95250141+mctaylors@users.noreply.github.com>
Co-authored-by: Octol1ttle <l1ttleofficial@outlook.com>
This PR fixes a fatal crash that occurs when the bot tries to send an
early notification for a scheduled event. An exception is thrown by
`string#Format` when the argument list provided doesn't match the
argument list in the template. This is fixed by correcting the template
and the argument list
Signed-off-by: Octol1ttle <l1ttleofficial@outlook.com>
This PR fixes the following bugs in ScheduledEventUpdateService:
- When a scheduled event is first added into ScheduledEventData, its
status update code will be skipped. This results in some messages not
being sent to the EventNotificationChannel
- When the status update code returns an unsuccessful Result, the status
in ScheduledEventData will still be updated, meaning that the code will
not retry.
---------
Signed-off-by: Octol1ttle <l1ttleofficial@outlook.com>
GuildUpdateService is a service that contains way too many
responsibilities with everything strictly coupled to each other. The
code is buggy, hard to refactor and swallows errors. This prompted me to
make this PR, which splits it into three independant services:
- SongUpdateService (responsible for changing songs presence);
- MemberUpdateService (responsible for updating member datas: unbanning
users, adding the default role, sending reminders, filtering nicknames);
- ScheduledEventUpdateService (responsible for updating scheduled
events: sending notifications, automatically starting events).
All of these services and their methods use Results to push errors all
the way up in the stack, making sure no error is missed. To make logging
and debugging easier, an extension method for `ILogger` was created -
`LogResult`. The method checks if the result was successful or if its
failure was caused by a user or environment error before logging
anything - providing cleaner code and logs. `ExceptionError`s will also
have their exception stacktrace and type logged (except in Remora code).
This PR also fixes an issue that prevented banned users from being
unbanned when their punishment was over.
---------
Signed-off-by: Octol1ttle <l1ttleofficial@outlook.com>
