Large batches and bursts
A burst is fetched in cursor order and attended to in priority order, and those are deliberately not the same thing. Nothing is skipped: the read position advances only past work that was accepted, so a burst larger than the day's allowance is held rather than trimmed. What a burst changes is which conversation is looked at first, not whether any is looked at.
Two orderings, doing different jobs#
- Fetch order
- Follows the mailbox's position — ascending UIDs on IMAP, the change log on Gmail. It is mechanical, it never skips, and it is what guarantees completeness.
- Attention order
- Follows
threads.priority, which the engine reads when it picks work. It is a judgement about what matters, and it is what stops a burst of newsletters burying a customer complaint that arrived in the middle of it.
Conflating the two produces the classic failure: a queue that is strictly chronological, in which the most urgent message of the day is answered after four hundred routine ones because it happened to arrive first. Needs You is ranked rather than chronological for the same reason, and correcting a priority genuinely changes behaviour rather than re-sorting a list, because the engine reads that column when it chooses.
So a burst does not delay the important thing in it. It delays the unimportant things around the important thing, which is the behaviour you would ask for if anybody asked you.
Where a burst meets the allowance#
| Situation | What happens | What it looks like |
|---|---|---|
| Burst fits within the allowance | Processed in one or more passes | Conversations fill; the queue grows and drains |
| Burst exceeds it | The excess is held, the position does not advance past it | A refusal in Needs You, with the remainder pending at the provider |
| The allowance resets | The pass resumes from the unadvanced position | The held remainder arrives, still in cursor order |
| The Owner's workspace | No plan, no gate | The bound is what the provider returns, not an allowance |
There is no trimming and no sampling. A refusal is recorded as a refusal — the audit trail records refusals precisely because a refusal is a decision — and the mail stays where it is. That is the difference between a burst being slow and a burst being lossy.
Why the screens do not fall over#
A burst is also a load test on every list that reads mail, and this is where the measured work matters. Query cost, counted as statements rather than wall-clock, was brought down and — the important word — made flat with page size: the triage strip went from 83 statements to 11, the workspace console from 89 to 17, and Home from 133 to 15. Flat means a workspace with four hundred new conversations costs what a quiet one costs.
The failure that motivated it is worth stating because a burst is exactly what provokes it. The conversation list used to read 400 rows and then do counting, filtering, searching and paging in Python over that slice. On a 430-conversation workspace the Closed tab read zero and page five was empty — not slow, wrong. A burst pushes a workspace across that kind of boundary in an afternoon.
The query cost that grows with the business and Headline numbers that stop at the page size are the two write-ups; the second is the one to read if a total on a screen looks suspiciously round after a busy day.
What to do during one#
Leave the fetching alone. Do not reconnect the mailbox to "unstick" it.
Result Reconnecting establishes a new position and is the one action that can turn a slow burst into a genuine gap.
Work Needs You from the top rather than the bottom.
Result It is ranked, so the top is where the consequential decisions are. Clearing chronologically wastes the ranking.
If a whole class of the burst should not be answered at all, block the sender rather than rejecting each draft.
Result A block is a
connect_memoryrow taggedblock:<channel>, so it holds across channels and into future conversations — Blocking a sender.If the burst is legitimate volume that keeps recurring, look at the allowance rather than at the mailbox.
Result Repeated refusals are a capacity signal, not a fault. They will keep resolving correctly and keep costing a day each time.
Questions#
Can a burst cause messages to be missed?
Not by the mechanism. The read position advances only past work that was accepted, so an oversized burst is held rather than trimmed. The way to actually lose part of one is to reconnect the mailbox mid-burst and establish a new position.
Will Connect reply to hundreds of messages automatically?
Only to the extent autonomy already allows and the allowance permits. A burst does not raise either. On a workspace at ask_before_send a burst produces a large approval queue, not a large outbox.
Does a burst distort the numbers on my screens?
It should not now — the counts that matter are computed in the database rather than over a fixed slice in memory. Historically that was exactly where distortion appeared, which is why the fix targeted flat cost rather than a bigger slice.