The daily email allowance

One register of every limit#

Limits used to live in two unrelated mechanisms with nothing tying either back to what the plan advertised, so a limit could be added to a plan and silently never wired to anything. Of nine that were listed, two were genuinely enforced, two were declared under key names nothing read, and the rest were numbers in a dictionary.

There is now one register, and every dimension in it declares how it is enforced, where — by module and function — or, honestly, that the feature it governs is not reachable yet. A test walks the register and fails if a reachable dimension has no enforcement site, which is the part that stops the drift coming back.

Reserved before the work, not counted after#

On ingest, the metered event is storing a message rather than fetching one. The reservation is taken before anything at all is written, and the loop stops rather than raising an error, because a workspace reaching its daily allowance is ordinary rather than a fault somebody must investigate.

That ordering was wrong once and the symptom is worth knowing. The reservation used to happen after the conversation row had been created and flushed, so a refusal left an empty conversation behind — right subject, no sender, no message, nothing has passed between you yet. A customer whose fifty-first message of the day was their own test mail saw a conversation that looked broken rather than a limit they had reached. Nothing is created now until the message is paid for.

On the send side the reservation is taken at the send boundary, after the channel's mode has been decided and before the provider is called. Where it is refused the draft is held with the reason in plain words, a warning is logged and an audit row is written — a refusal is a decision, so it is recorded like one.

Why the cursor does not move#

This is the most consequential line on the page. When ingest stops for want of allowance, the mailbox's read cursor is not advanced. The sync records that it happened, says so on the mailbox, and leaves the position exactly where it was.

Advancing it would be worse than it sounds. The window containing the refused message would be marked done, the next incremental sync would start after it, and that message would never be collected again — not deferred until the allowance resets, gone. Holding the cursor costs a re-fetch of messages that are already stored, and the duplicate check skips those without spending anything.

The mailbox says so in words a person can act on: today's inbox allowance is used up, new mail is waiting, and it is collected when the allowance resets. The sync result reports the stop rather than swallowing it, because a sync that returns fewer messages than the mailbox holds must say why or it reads as data loss. It also surfaces in Needs You.

What a spent allowance does not do#

• It does not lose mail. Unread messages stay unread at the provider until there is allowance to store them.
• It does not delete a draft. A held reply keeps its words, including any edit you made, and is sent when there is room.
• It does not stop you reading. Everything already in the workspace is unaffected.
• It does not apply to the Owner, who has no plan and no gates — see The operator's workspace and a customer's.

A reservation is also given back where Connect knows the work did not happen. The exception is an uncertain send: the message may have gone and may already have been counted, so the reservation stands rather than being handed back on a guess. That reasoning is set out in Proof that a message was sent.

Questions#

Related#

• Account and access
• Sending email
• Syncing an inbox
• Mailbox health
• How a mail cursor loses messages, and how to stop it