Mailbox Service — Backlog: Issues, Gaps & Improvement Scope

Last Updated: 2026-10-07 Status: Active Purpose: Known bugs, missing features, and improvement opportunities found during the 2026-09-14 mailbox + newsletter audit. Mark items done with a date when fixed. Do not delete fixed items.

This is the mailbox worker's half of the audit report at .claude/plans/take-your-time-bubbly-hejlsberg.md (finding ids MB- backend, MF- dashboard). Newsletter and comms findings are tracked in docs/newsletter/backlog.md and docs/communication/backlog.md.

Fixed Items

2026-09-14 — Mailbox + Newsletter audit, Phase 0 (security & money)

Branch audit/phase-0-security, on main as 321757ea. Mailbox-relevant fixes:

2026-09-15 — Mailbox + Newsletter audit, Phase 1 (correctness hotfixes)

Branch audit/phase-1; merged to main and deployed (Phases 0–3 are on main and live). 9 PRs (P1–P9b); rows below cover mailbox (P1, P2, P3).

2026-09-28 — Phase 5 PR1 (Inbox / Sent / Archived + delivery status, backend)

Branch audit/phase-5; deployed 2026-10-05 together with Phase 4 (workers, schemas, dashboard, website). It needed scripts/apply-2026-09-phase5.mjs (--columns before the worker, --backfill and --indexes after) and scripts/backfill-delivery-status.mjs after comms ships. The rollout record does not say whether the delivery-status backfill was run: confirm it, because mail sent before the deploy shows "sent" forever without it.

2026-09-29 — Phase 5 PR2–PR5b (sections UI, direct uploads, typed client, inbox helpers + hooks)

Not yet deployed. PR3 needs the mailbox worker and the gateway deployed before the dashboard (the dashboard falls back to the proxied upload until they are).

2026-09-29 — Phase 5 PR6 (mailbox UX)

2026-10-05 — Phase 5 Track M closing notes (decisions, descope, coverage)

Track M (PR1–PR7) is built. Three things were decided or recorded rather than built, and two PR12/PR13 changes touched the mailbox module.

Descoped to Phase 6 (decision of 2026-10-05): the rest of plan 5.2 / PR5. What shipped is the first two slices only (inbox/format.ts, inbox/forward.ts, and the hooks useUnreadCounts, useDesktopNotifications, useInboxShortcuts, plus MF-30/32/46). Not built: the hooks useInboxList, useOpenThread, useOptimisticSends and useUndoableComposer (the composer dedupe between ReplyBox and ComposeDock), and therefore their tests, which drop out of Phase 5's exit list with them. Non-test files under modules/mailbox still over 400 lines (measured 2026-10-05):

inbox/HtmlBody.tsx (454 at the audit) fell under 400 incidentally when its height mechanism was extracted into the shared src/lib/iframe-height.ts for the newsletter's Custom HTML block (behaviour unchanged; its 8 auto-height, 15 sanitize and 2 theme tests pass untouched). MailboxPage.tsx grew back from 984 after the MF-23/24/40 work, so the split is bigger than the original estimate; it is the largest single item for Phase 6.

MF-47 (the sender name collapses an open message): deliberately not changed. The name is a real <button> with aria-expanded and title="Collapse this message", keyboard- and screen-reader-operable, and it implements the module's documented model ("a collapsed card is a button that expands in place, so nothing is ever hidden behind navigation"), the Gmail conversation pattern. The audit's concern was surprise, not accessibility. If it proves confusing, the lower-risk fix is a visible chevron beside the name rather than changing what the name does.

mailbox:send (MF-49) test coverage. The plan listed a dedicated send-permission.test.ts; none was added because the rule is already pinned where it is enforced: test/access.test.ts (reply and compose both 403 on a per-account send grant alone; org admins still allowed regardless of the permission list) and test/upload-ticket.test.ts (a ticket is refused on an ACL send grant alone and minted once mailbox:send is present), with the catalogue and the Member baseline in packages/core-access/test/catalogue.test.ts. A separate file would only duplicate those.

Accessibility gate (Phase 5 PR13). pnpm --filter seller-dashboard test:a11y runs axe over the inbox surfaces: the thread list (unread, read, selected, delivery-problem, empty), the message card (bounced recipients with the fix-it hint, inbound, collapsed) and the reply box (collapsed and open). No serious or critical findings in any of them. The one violation axe raised first (an unnamed hidden file input) was a jsdom artefact, since Tailwind's .hidden is display:none in the app, handled with a narrow exclusion rather than a disabled rule. A canary suite proves axe reports real problems under jsdom, and mutations of the real components (a listbox losing its name or role, an invalid role on a reply field and on the outcome panel) all fail the suite. Details in docs/newsletter/backlog.md (PR13).

Rich-email viewer, after the Phase 5 review pass (commit 9ba5d4c3). The viewer shares its height script and CSP with the newsletter's Custom HTML block, so two review findings reached it. (1) The reported height was max(documentElement.scrollHeight, body.scrollHeight), which never drops below the frame's own current height, so it could only grow; it now reports the content's box (body.scrollHeight against the html element's bounding height), checked in real Chrome including a live shrink. Its 8 auto-height tests are unchanged. (2) The meta CSP gained frame-src, object-src and form-action 'none'. For the viewer this is defence in depth: DOMPurify already strips iframe, object, embed, form, meta and base before the srcdoc is built (not re-tested in a browser here). Its resetKey is now the sanitized HTML string rather than the memoized object around it. The residual described in docs/newsletter/backlog.md (a remote document reached by a link click or <meta refresh> keeps allow-scripts) applies to the viewer only if the sanitizer is bypassed.

2026-10-07 — Inbox toolbar and the conversation list

Shipped across d07b2b2c, dd65fb89, 891a9390 and the commit that adds the mailbox tag. Recorded here because they were fixes to gaps found while using the inbox, not items from the original audit.

Open (found 2026-10-07, not fixed here): conversation rows with their hover actions are role="option" elements that contain buttons. axe reports this as nested-interactive (serious). The existing accessibility test for the list never gives rows any actions, which is why it has always passed, so the gate does not cover rows as a keyboard or mouse user sees them. It predates the mailbox tag (a list with the tag but no actions is clean). Not fixed because the cure is structural: the actions would have to move out of the option (a sibling positioned over the row), which changes the Tab-order model MF-23 built (only the selected row's two buttons are Tab stops, located by closest('[role=option]') in its tests) and the swipe wrapper. Owner: later, with a test that renders a row with actions through axe. Until then the accessibility claim above ("no serious findings") holds for the list without row actions only.

2026-10-07 — Designed email shown the way Gmail shows it

The same message looked right in Gmail and broken in the Mailbox. It showed plain text first. The rich view had no styling, so a black button became a bare blue link. Images were dashed boxes until you clicked "Load images". Two commits: 087d896a (viewer) and the image-proxy commit that follows it.

Deploy order (not done): mailbox worker, then gateway (it adds the IMAGE_RATE_LIMITER binding in its tracked wrangler.toml), then push the dashboard. Pushed first, the dashboard would only see unproxied bodies and block their images, as today. The mailbox needs no new secret; PUBLIC_API_ORIGIN defaults to https://api.vlozi.app.

Limits: images are fetched when the reader opens the message, so a sender with no pixel can still see that an image was requested and when; they get our server's address, not the reader's. Web fonts in @font-face still don't load in blocked mode (the CSP keeps font-src to data:); text falls back to the email's own font stack, as in Gmail.

2026-10-10 — The Gmail-style redesign (branch mailbox/gmail-redesign, not pushed)

The inbox page was rebuilt: folders in the header's row 2, a full-width list with Inbox tabs and a bottom bar, several mailboxes at once with saved groups, a full-width reader with a docked reply bar, compose with the From pill, and a phone layout with its own bottom bar. It replaces InboxToolbar and MailboxPicker (the chip strip above). The mailbox worker gained accountIds, categories, sender names on threads and GET /v1/messages/:id/unsubscribe (49f9a327, not deployed). Everything that needs bigger server work (star, server drafts, snooze, spam/trash, scheduled, important, AI drafting) is shown disabled as "coming soon". What shipped, the rollout order, the backend-later list (MR-1 to MR-11) and the gap log (MR-G1 to MR-G7): docs/seller-dashboard/mailbox-redesign.md.

2026-10-10 — Starred, Drafts, Spam and synced groups (branch mailbox/folders-backend, not pushed)

Phase 6.2 (part) and 6.3 (drafts). Per-person stars, private drafts on every device, a Spam folder with reported/blocked-sender/DMARC rules and "Empty spam now" (the worker's first delete, lib/purge.ts), saved mailbox groups on the server, POST /threads/bulk, and personal realtime events. Migration scripts/apply-2026-10-folders.mjs (founder runs it). Details, rollout and the feature gate: docs/seller-dashboard/mailbox-redesign.md, section "Starred, Drafts, Spam and synced groups".

2026-10-10 — Trash (branch mailbox/trash)

What it adds:

• Delete moves a conversation to Trash; Move to Inbox restores it; Delete forever and Empty Trash delete for good.
• Everything in Trash is deleted for good after 30 days, by a per-workspace Durable Object alarm. This is the mailbox's first automatic deletion, and a step on G30.
• Migration: scripts/apply-2026-10-trash.mjs.

Details: docs/seller-dashboard/mailbox-redesign.md, section "Trash".

2026-10-11 — Strict team access (branch mailbox/strict-access, not pushed or deployed)

Nobody reads a mailbox without being added to it, the workspace Owner and Admins included. Each mailbox has its own Viewer, Sender, Manager and Owner roles on top of the workspace role. Access can be temporary, people ask for it with a request that only that mailbox's Owners answer, and every change goes in the mailbox's activity log. Someone who leaves the workspace loses their access at once, and ownership passes on.

Touches manager, comms, the mailbox worker and the dashboard (the Mailboxes page, inbox, navigation, bell and Team page). It needs one migration, apps/mailbox/scripts/apply-2026-10-access.mjs (five phases), and one core-DB script, apps/manager/scripts/catalogue-mailbox-2026-10.mjs. The founder runs both.

Decisions D1 to D31, the build log, the rollout order and the gap log TA-G1 to TA-G20: docs/mailbox/team-access.md. This is the foundation for Phase 6.1 (assignment, notes, presence). Live since 2026-10-11.

2026-10-11 — "Sent by" (live 2026-10-12: mailbox worker 95b5ab06, main ffaf0356)

Every outgoing message records which teammate pressed Send. The mailbox's own people see "You" or the teammate's name on each sent message, and a "Rahul: …" prefix in the list when the newest message went out. The recipient still sees only the mailbox address. Before this round, every outgoing message in a shared mailbox said "You", whoever sent it.

It needs apps/mailbox/scripts/apply-2026-10-sent-by.mjs --columns, run before the worker deploy. Decisions D32 to D36, rollout and gaps TA-G21 to TA-G25: docs/mailbox/team-access.md, section "Sent by".

2026-10-14 — Review of the 2026-10-09 to 10-12 work (RV-1 to RV-12 fixed on branch mailbox/review-fixes, not deployed; RV-13 to RV-15 open)

A read-only review of everything since 00ccd56e (62 commits: redesign, folders, Trash, strict access, "Sent by", private attachment storage) at e071663d. At review time the worker (795 tests) and the dashboard mailbox module (569 tests) passed, and both typechecked. No critical findings. Access control holds: both locks are checked on every read path, there is no owner bypass, ids from requests are tenant-scoped, requests can't be answered twice, and realtime events reach only the right sockets. The dashboard–worker contract matches; the one-click unsubscribe's SSRF guard matches the image proxy's; the email viewer's proxy exemption, CSP and sandbox are unchanged. "Verified" means re-read in the code after the review; the rest are high-confidence code paths from the review.

How RV-1 to RV-12 were fixed (2026-10-14, founder's decisions: conversations stay in Primary; a blocked person's reply goes to Spam on its own; polish RV-13 to RV-15 later). No migration. Every fix has a test that fails without it (mutation-checked: 11 purge/ingest, 12 categories/spam/access, 11 dashboard).

Doc drift: TA-G1 says the attention count cleans up departed people (it doesn't; People and the directory do); the old POST/DELETE /accounts/:id/access routes "kept for one deploy" are still there; approve/deny check the approver's workspace role from the token, not live (TA-G15); MailboxPage.tsx is about 1,880 lines (MR-G7 says about 1,330).

2026-10-15 — Review of the RV fixes themselves (branch mailbox/review-fixes @ befaf754, not deployed)

A second, read-only review of the 8 fix commits. Each finding below was re-checked in the code; "probe" means a throwaway test reproduced it (since deleted). Owner for all: the next fix pass on this branch, before it is pushed — except RF-2, which needs the founder's decision first. The branch should not be deployed until at least RF-1, RF-2, RF-4 and RF-5 are fixed: they leave RV-4, RV-11 and RV-10 only partly fixed.

Fixed 2026-10-15 (same branch, then pushed to main and deployed): RF-1, RF-2, RF-3 in 9988908b (one rule, threadAccepts, for which threads a message may join — both findThread steps and a routed reply; the reference match prefers the newest cited message; the DMARC return needs the same address as every failing mail in the thread, the founder's option 1 made stricter because anyone can forge someone@gmail.com and reply from their own Gmail; a blocked sender on an auth_fail thread makes it blocked_sender); RF-4 and RF-7 in 8fc1771f (the old route checks Use mailboxes; the rollback refunds first, deletes in one statement only while no mail has arrived, and otherwise keeps the mailbox with its charge and answers 503 PROVISION_INCOMPLETE, which the create dialog shows and reloads on); RF-5 in d424b0aa (messagesDeleted from both routes; the buttons keep going on progress and say "still deleting" when they stop with some left); RF-6 in ed2bfe4b (seed once the drafts load and remount an untouched box; auto-filled recipients aren't content; the autosave writes only on a change). Every fix mutation-checked (27 breaks, all caught).

Second pass, 2026-10-15 (branch mailbox/rf-followups): RF-12, RF-13, RF-14 in 22ee6343 (ticks aren't the target under the "Sending your message…" pane; sign-out also clears vlozi.mbx-groups.* and turns browser-storage writes off until the page goes — the login page turns them back on; presets compare days for an N-day request and end before the cap for a fixed end). RF-8, RF-11, RF-15, RF-16 in a9414eab (the purge leaves a thread whose message count changed after its snapshot for the next call, and ingest skips a Spam message's bytes when an Empty spam deleted it; the threads that can finish go first; bulk nudges part-deleted ones and a single Delete forever that loses to a restore answers PARTLY_DELETED; locks in id order and retries a deadlock once; an undone first mailbox hands the default on; a create refunds only a charge it made). 19 more breaks, all caught.

Not changed, with reasons (owner: founder, if any becomes worth it):

• RF-9: a revive racing a normal ingest on the same thread can over-count message_count by one. It needs two messages for one thread at the instant it is purged, and the fix would be a count on every inbound message.
• RF-10: a revived thread follows the new-thread rules (a DMARC fail starts it in Spam). That is the conservative choice for a conversation that was being deleted for good. Outbound revives need no delivery-problem flag, since the pending events are drained right after.
• RF-16 (other half): comms /internal/mailbox-refund cancels the recurring charge by address, so a double-submitted create that loses can cancel the winner's. The fix (return and cancel only this call's registration) is a communication-worker change and is left for that worker's next deploy.
• Untestable here: the RF-8 deferral and the id-order locking need two connections, and PGlite has one. Both were checked by reasoning about READ COMMITTED. A one-off check on a Neon branch is possible if wanted.

RV-13 to RV-15, fixed 2026-10-15 (branch mailbox/rv-polish, the founder said go). Each item was re-checked against the code and reproduced first.

• RV-14 (f13ec532, access screens):
  • a role change keeps the end and the note;
  • the person a request is for may cancel it;
  • "ends today" is counted in calendar days;
  • Remove on Domains only with comms' sender permission;
  • Setup's review reads People (no false "Just you") and says when the alias is already a mailbox you aren't in;
  • "Ask for Sender" only when the workspace role can send.
• RV-13 (5227e262, inbox):
  • j/k at either end keep the open conversation;
  • a stale list answer neither ends the skeleton nor shows an error;
  • the Inbox badge counts open threads only (not Spam/Trash);
  • an Escape a menu or dialog used doesn't close the conversation;
  • keys inside an open menu or dialog stay there (found with it: # in "More actions" trashed the conversation);
  • a ?mb=g: link and a ?view= folder wait for the worker's features. A folder it lacks falls back to the Inbox quietly.
• RV-15 (80ab4467, worker):
  • read marks reach a message whose sender's clock runs ahead;
  • "named Owner" says why nobody took over;
  • approving keeps a step-down's way back (D15);
  • reply is a 404 to non-members;
  • socket age limit 15 min;
  • a busy mailbox is a 503-and-retry on the removal call and never fails a page;
  • no mailto: unsubscribe link.
• 31 deliberate breaks, all caught.

Still open, with owner and reason:

Checked and correct (summary): the purge's snapshot logic, zero-message threads, concurrent purges, tenant scoping, bind counts, neon-http result handling and termination; RV-3's SQL and code agree (120 combinations) and last_outbound_at is backfilled; every sign-out site uses signOutCleanly, SSR-safe; RV-1's ref timing; RV-9's clamp agrees with the server; RV-12 never deletes an existing mailbox (made.created is the right signal), and a retry after a refund is charged again.

What is left (read 2026-10-07; replaces the older "Still open" paragraph, which was out of date)

The old paragraph said the shared-inbox foundation (per-user read state, reply-to/reply-all, participants, mailbox lifecycle, send bounds, the server-side sanitiser) and the migrations baseline were open. They are not: Phases 0–3 are on main and live, and Phases 4 and 5 were deployed on 2026-10-05. The mailbox migrations baseline exists (apps/mailbox/drizzle/0000_phase3_baseline.sql) as a review artefact only; production keeps using the hand-written scripts/apply-*.mjs, because Neon's HTTP driver has no interactive transactions. Bookkeeping still owed: this file has Fixed rows only for Phases 0, 1, 5 and the toolbar work; the mailbox items shipped in Phases 2–4 (the plan's PR maps for MB-04 to MB-07, MB-10 to MB-14, MB-16 to MB-18, MB-20, MB-22 (indexes), MB-23 to MB-25, MB-27 and P3-N1 to P3-N14, and dashboard MF-08, MF-10, MF-13, MF-15 to MF-19, MF-29, MF-31, MF-45) were never added as rows.

Bugs and gaps still open (the first three re-checked in the code on 2026-10-07):

Page split, done 2026-10-21 (branch dashboard/mailbox-split, not pushed): MailboxPage.tsx went from 1,940 lines to 629. Its state and behaviour now live beside it in inbox/: useInboxList (the list, paging, ticked rows), useOpenThread (the open conversation, its URL, dwell-to-read, older pages, scrolling), useOptimisticSends, useInboxRefresh (the coalesced refresh of RV-1, and the polls), useMailAccounts, useCategoryPreviews, useScopeFlip, thread-actions and bulk-actions, shortcut-actions, commands, scope-title, error-copy, ListNotices (FolderNotice, ListContent, PhonePager) and startForward. Code moved word for word; the page tests passed unchanged after every step. Breaking one thing in each new module showed nine guarantees no test covered (a late list or thread answer landing in the view you left, dwell-to-read with the tab hidden, losing a mailbox closing its open conversation, the picker exclusivity, tab previews, Forward keeping a draft, the no-results copy, Compose in ⌘K needing send rights); each now has a test, and all 17 breaks are caught. The page is still over 400 lines: what is left is the wiring between the hooks and the layout, and splitting the layout further would mean components taking 30-odd props.

Still open from plan 5.2, deliberately: useUndoableComposer (ReplyBox, 724 lines, and ComposeDock, 588, keep their duplicated send and error code), and SendingDomainsPage, mailbox.api.ts, MailboxAdminPage, AttachmentTray and ThreadList are over 400. Also left: MF-47, the zod contract packages, and a dedicated send-permission test.

Found while verifying the split (not mailbox code), fixed 2026-10-21 on chore/lint-and-flaky: notification-bell.test.tsx (and, it turned out, service-bar.test.tsx) failed now and then in the full dashboard suite. Both wait for code loaded with dynamic import(), and under full-suite load the first, cold import outran the tests' 1-second wait. The tests now load those modules once before running and wait 5 seconds, as EmailComposer.test.tsx already did; two full runs in a row passed. Two lint errors already on main are fixed too: src/hooks/use-billing.ts used any (an error body that isn't text no longer becomes "[object Object]"), and src/modules/engagement/components/sources-panel.tsx set state inside an effect (loading is now worked out from which breakdown the answer is for, so a late answer for another breakdown never shows; new test).

Product features not started (Phase 6 menu): 6.1 assignment, notes and collision presence; 6.2 labels, snooze and bulk actions (see the planned section below); 6.3 server-side drafts, canned replies and scheduled send; 6.4 message-body search with from: / to: / has: (the trigram indexes exist); 6.5 custom-domain inbound (until then custom-domain mailboxes are send-only); 6.6 mailbox MCP tools, Flows triggers and contact-intelligence ingest; 6.7 AI triage and drafting. 6.8 (delivery status in the thread) is done.

Ops and hygiene (not started): stuck-state alerting for the mailbox (R2 write failures, realtime publish failures); per-caller internal keys instead of one shared INTERNAL_KEY; plan gating (mailbox seats from the plan registry); the mailbox wrangler.toml is untracked, so its bindings (MANAGER_SERVICE, MBX_SEND_LIMITER) exist only in the runbook; the mailbox is also reachable on a public workers.dev address (gap G54).

Owned by the data-lifecycle work (SES gap log, Track B): the mailbox deletes nothing, with no message, thread, attachment or R2 delete (G30); mail to an unknown recipient is accepted and silently dropped (G11, G12): fixed, deployed 2026-10-21 (main 4e24ab6b; comms 94c8834c, rollback fd6d99ec; mailbox 3b790d0e, rollback 6dfeb7b6): the sender now gets a bounce; a failed lookup never bounces.

Launch gate, not a code task: SES is still in the sandbox, so mailbox mail to arbitrary outside addresses is blocked until the separate tenant-mail request (Phase B). Replies from the vlozi.app role mailboxes go through Resend and work; a reply from a mail.vlozi.app mailbox is refused until tenant sending is enabled.

The audit report, for the full finding text: .claude/plans/take-your-time-bubbly-hejlsberg.md.

Planned, not started: manageable labels and grouping (noted 2026-10-07)

Decision (founder, 2026-10-07): the derived mailbox tag on each All-view row (b81c3e41) is enough for now. Some day we build the complete version: labels you can create and manage, and grouping of the list. This section keeps what was worked out so that day starts from a plan, not from zero. Nothing here is built.

What "complete" means

Smaller ideas that fit in the same work

• Click the mailbox tag on a row to filter to that mailbox (needs care with Tab order inside a row).
• A "Personal / Shared" tag derived from the grant count (already suggested in docs/communication/communication-mailbox.md).
• Automatic "Automated" / "Newsletter" tags from the message kind the worker already classifies (the kind would need to be on the thread DTO).
• A Flows trigger such as mailbox.thread.labeled, and MCP tools to list and apply labels (roadmap 6.6).
• Rules that label automatically (by sender, subject or mailbox). Later, once manual labels are in use.

Do first, before adding any new control to a row: fix the open accessibility item above (a row with its hover actions is a role="option" containing buttons). A label picker on every row would be one more nested control, so the row structure should be fixed once, not worked around again.

Effort, as estimated in the design pass: labels with the panel, applying and filtering about 5 to 8 days; grouping about a day on top, more if it has to page per group; the mailbox colour picker about half a day. The audit plan's Phase 6.2 (.claude/plans/take-your-time-bubbly-hejlsberg.md) is the roadmap entry this belongs to.