@JPBM135 is attempting to deploy a commit to the discordjs Team on Vercel.

A member of the Team first needs to authorize it.

The latest updates on your projects. Learn more about Vercel for Git ↗︎

This looks decent, but a couple points to consider:

1. Can we move the locking into createCase? That's really where it matters, and might cut down on code duplication.
2. I'd really like to see locking handled with a try...finally block to ensure the lock is properly disposed once the resource is no longer needed. Unfortunately JS doesn't have a good way to do this, so I'd recommend either just always using a try...finally block or passing a callback to the locking function with the code that requires the lock; callback is probably the cleanest and most explicit about the lock boundaries.

1- The thing about moving into createCase is, it does not solve possible case duplication, since a mod can be in the confirmation screen and another one triggering the action, since all the tests and validations are made prior to confirmation there is no current way to check this

2- I couldn't find a good way to do this either, but I will deff give another look into it

2. I'd really like to see locking handled with a try...finally block to ensure the lock is properly disposed once the resource is no longer needed. Unfortunately JS doesn't have a good way to do this, so I'd recommend either just always using a try...finally block or passing a callback to the locking function with the code that requires the lock; callback is probably the cleanest and most explicit about the lock boundaries.

Found a solution for this, implemented the member lock in the command handler, only using extends when needed

Found a solution for this, implemented the member lock in the command handler, only using extends when needed

Neat that's pretty clean.