Abandon Processing
Drops the current event entirely – no Conversational Flow is triggered and no response is sent to the user.
The Abandon Processing node stops event processing in its tracks. When execution reaches this node, the Handler ends immediately, no Conversational Flow is triggered, and no response is sent to the user. The event is silently dropped.
Available in: all Handlers.
When to Use
Use Abandon Processing when you want to filter out or ignore certain events. Common scenarios:
- Suppress very short messages – If the user sends a single character or an empty message, abandon processing rather than triggering an LLM response
- Block input during a specific state – If a flow is already active and should not be interrupted, abandon the new input
- Reject unsupported languages – If language detection identifies a language you don't support, abandon rather than processing in an unexpected language
- Rate limiting / spam prevention – Silently drop repeated identical inputs within a short time window
Behavior
- Handler execution stops immediately at this node
- No flow is activated or notified
- No message is sent to the user
- The pipeline waits for the next event
Contrast with Continue Processing
| Abandon Processing | Continue Processing | |
|---|---|---|
| Passes event to flows? | ❌ No – dropped | ✅ Yes |
| Response generated? | ❌ No | ✅ Yes (by flows) |
| User sees anything? | Nothing | Normal response |
Be careful not to accidentally route all events through Abandon Processing. If a Handler always abandons, the virtual being will never respond to any user input. Always ensure there is a clear path to Continue Processing for normal cases.