Checks

Most commands need a few things settled before they run. Is the caller in a server? Do they hold the permission? Have they used this command in the last minute? This tab covers the checks that decide whether a handler runs, and the middleware that runs around them.

When someone runs a command, clicks a button, or submits a modal, seedcord runs a series of steps, from your handler's constructor to the last after() call. That run is a dispatch. Each one runs in this order.

an interaction arrives
│
├─ 1. seedcord builds your handler      your constructor runs here
├─ 2. each middleware's execute()       lowest priority first
├─ 3. each gate's check                 left to right
├─ 4. each effect gate's commit         only once every check passed
├─ 5. your handler's execute()
└─ 6. each middleware's after()         reverse of step 2, every time

a throw or a refusal in 2, 3, 4, or 5 skips straight to 6

A gate can read what a middleware wrote, since every middleware runs first.

• Gates put a check on a handler with @Gated. The pages after it cover the permission gates, writing your own, combining several, and gates that change state.
• Middleware runs for every handler of the kinds it lists. The dispatch context carries what it computes to the handler and its gates.
• Cooldowns limit how often a command runs. The rate limiter counts uses against any key you build.
• Permissions in a handler and changing roles cover checks that need a value your handler reads first, like the member a command targets.