A drop route that returns success lies to upstream sync
Debugging why a newly-added LLM classifier was never firing on inbound emails despite being deployed and enabled.
A routing/filter system that silently drops messages but returns success to its upstream caller is a deception, not a no-op. In this case unresolved inbound emails hit a route configured as mode=drop which returned status=stored to the upstream IMAP sync agent (so the agent dutifully advanced its high-water mark) while writing nothing — no DB row, no JSONL append, no downstream classifier invocation. The classifier appeared broken; it never even ran. The fix has two parts: (1) drop should still emit observability so downstream consumers can detect zero-rate as a configuration problem, not a silence; (2) any code path that needs to inspect a message (classifier, hooks, side-channels) must run BEFORE the route decision, not after, or the route decision must persist enough state for the side-channel to attach later.
When wiring a new processing stage into an existing pipeline that has a drop or filter step upstream, trace one message end-to-end through the actual deployed routing config, not the design diagram. The diagram shows what the pipeline could do; the live config shows what gets dropped.