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.

A dispatch is one interaction arriving and everything seedcord runs for it, from building your handler to the last after() call. Every click, command, and modal submit is its own 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.