Handler Group Precedence
Which message watchers fire first and how propagation works in Alita Robot.
Handler Group Precedence
Section titled “Handler Group Precedence”gotgbot dispatches incoming updates to handlers in ascending group number order. Lower group numbers fire first. Within the same group, handlers fire in registration order. A handler returning ext.EndGroups stops all further group processing for that update. ext.ContinueGroups allows downstream groups to continue firing.
This page documents every registered message watcher with its exact handler group number, verified from source code.
Precedence Table
Section titled “Precedence Table”| Group | Module | Handler | Filter | Return on Match | Notes |
|---|---|---|---|---|---|
| -10 | Captcha | handlePendingCaptchaMessage | nil (all messages) | EndGroups | Intercepts messages from users with pending captcha; stores and deletes message |
| -2 | Antispam | (inline closure) | message.All | EndGroups | Rate-limits spamming users; passes through if not spamming |
| -1 | Users | logUsers | message.All | ContinueGroups | Logs user activity; never blocks propagation |
| 0 | All modules | Commands, callbacks | Various | varies | Default group; standard command handlers |
| 4 | Antiflood | checkFlood | message.All | EndGroups on flood, ContinueGroups otherwise | Flood control; skips anon admins and media groups |
| 5 | Locks | permHandler | message.All | EndGroups on violation | Permission-based locks (can_send_messages, etc.) |
| 6 | Locks | restHandler | message.All | EndGroups on violation | Restriction-based locks (stickers, animations, etc.) |
| 7 | Blacklists | blacklistWatcher | non-command, non-media-group | ContinueGroups (always) | Checks words against blacklist; action taken but processing continues |
| 8 | Reports | (handler) | message.All | varies | Report tracking |
| 9 | Filters | filtersWatcher | non-command, non-media-group | ContinueGroups (always) | Matches filter patterns; sends configured response but does not block |
| 10 | Pins | (handler) | message.All | EndGroups | Anti-channel-pin watcher |
Propagation Behavior
Section titled “Propagation Behavior”Interaction Examples
Section titled “Interaction Examples”Scenario 1: User with pending captcha sends a message
Section titled “Scenario 1: User with pending captcha sends a message”- Captcha (group -10) intercepts the message, stores it in the pending queue, and deletes it from the chat.
- Returns
EndGroups. Nothing else fires. - After the user completes captcha verification, stored messages are replayed.
Scenario 2: User sends a flood of messages
Section titled “Scenario 2: User sends a flood of messages”- Captcha (group -10) passes through (no pending captcha).
- Antispam (group -2) passes through (not yet rate-limited).
- Users (group -1) logs activity, continues.
- Commands (group 0) fire normally for earlier messages.
- Antiflood (group 4) triggers after the flood threshold is reached, returns
EndGroups. - Locks, blacklists, filters, and pins are all skipped for that message.
Scenario 3: Message matches both a blacklist word and a filter
Section titled “Scenario 3: Message matches both a blacklist word and a filter”- Captcha (group -10) passes through.
- Antispam (group -2) passes through.
- Users (group -1) logs activity, continues.
- Commands (group 0) — not a command, passes.
- Antiflood (group 4) — not flooding, continues.
- Locks (groups 5-6) check permissions. Message passes (no lock violation).
- Blacklists (group 7) matches the word, takes configured action (e.g., warn user), returns
ContinueGroups. - Reports (group 8) tracks the message.
- Filters (group 9) matches the filter pattern, sends the configured response, returns
ContinueGroups. - Pins (group 10) checks for anti-channel-pin conditions.
Both the blacklist action and the filter response are triggered for the same message.
Related Pages
Section titled “Related Pages”- Request Flow — Full update processing pipeline
- Module Pattern — How modules register handlers