I thought that I was careful and avoided opportunities for deadlocks. I was incorrect. Both DashMap::get() and DashMap::get_mut() can deadlock, which are used extensively. This should be rare but was the core issue behind #23. Either a more measured approach to acquisition needs to be implemented or those maps need to be swapped for an async type.

Currently, there is no logging happening in the v2 pre-release. This will make fixing bugs rather difficult.

Ideally, any panics or issues with Discord would be logged locally and, when possible, sent to the error log on the dev server. The after_command event handler should be helpful for this.

When a match result is entered (and maybe even when its confirmed), the reply should include a match status embed. That way, players know what they are entering/confirming.

Some things, such as making duplicate roles, seem to cause hang ups. This seems somewhat random, but creating multiple tournaments with the same name seems to do the trick. This also seems to cause everything to hang up. No new commands will be processed (from any server) until the hang up is resolved.

What went wrong:

Between constructions of the Round status embed, the player order can change. This stems from the Round storing players in a HashSet.

Expected behavior:

This ordering should be consistent.

General Info:

There is an issue out in SquireLib (Rounds Track Player Order) that will help remedy this.

Description:

Currently, commanders don't appear in deck embeds. This is because the sorted deck struct only consumes the mainboard of a deck.

The solution you'd like:

The sorted deck should also track commanders.

The status and standings messages are updated automatically. This is great, but it makes it hard to know if they have been updated (besides waiting). There should be a command to force update these.

Serenity has macros that allow you to add use cases and examples for commands. These examples show up in the help command. All commands need to be annotated with these.

According to the specs on the MSTR

Added a parameter to the player#getMatchPoints so that the tournament object can pass the number of players per pod to it. This way it still works for 1v1 events.

Ignore the whitespace changes, my editor automatically removes those on save (which is a good thing actually)

Description:

Often, table numbers suffice as round identifiers for active rounds. This should be supported by SB (and SquireLib).

The solution you'd like:

To specify a table number, the number can be prefixed a T in order to distinguish between round numbers.

Alternatives:

Alternatively, match numbers are likely to be used less as identifiers, so we can default to table numbers and use R and/or M to specify match numbers.

Any command that wraps a GuildTournamentAction::Operation does not update the tournament status, but it should. Unfortunately, not all operations should update the status. For ease, it will probably be easiest if this always updates the status. This should add minimal overhead.

What went wrong:

A player left the server and should have been automatically dropped. This did not happen. Instead, the tournament admin had to drop the player using that player's id. This causes a panic when SB tries to remove that player's role. This led to the tournament admin being confused about if it worked.

Solution:

Remove the unwrap when getting a player to remove their role.

What went wrong:

Often, the deck check command doesn't work. This is seemed to happen after the first round, but I have not been able to reproduce the behavior. First occurred during Okotoberfest 2022.

Description:

Currently, a command has a TTL of 10 seconds before the logging system thinks a panic has occurred. This should be more dynamic as commands that send multiple requests to Discord take much longer.

The solution you'd like:

We should log every await point and/or call to Discord. The logging system should then only detect when more than 10 seconds have passed since the last logged operation.

There have been a number of bugs found whose origin is a dubious unwrap call. We should have a goal of removing every call to unwrap to avoid such problems.

It is possible that, for one reason or another, parts of a tournament's representation in a server fall out of sync with the actual tournament object, ex a round is created but the role doesn't exist or people don't have the role. There should be mechanisms to help sync the Discord components with the tournament. Note that the reverse is not true. For example, removing a role/channel from Discord should not remove a match.