The message-open perf drilldown traced slow user-tapped cold opens to IMAP contention: with effectively one working connection, an interactive fetch queues behind background backfill, and Gmail additionally throttles connect-per-op (Gmail cold opens measured 31–40s vs Outlook 2–3s). Two levers already exist/are in flight: #357 landed connection reuse (warm connection), and #355 (in flight) pauses backfill during an open. This spike explores the orthogonal lever: a small connection pool (2–3) so an interactive cold open runs on its own connection rather than waiting on — or having to pause — backfill.
Goal
Determine, with real measurements, whether a small number of concurrent IMAP connections (2–3) meaningfully improves user-tapped cold-open latency vs today's single-connection model — without tripping per-provider connection limits or regressing backfill throughput. This is a spike: deliverable is a prototype + data + a ship/no-ship recommendation, not production-hardened code.
Approach
Prototype a bounded IMAP connection pool (size configurable, default 2–3) behind a dev flag, building on the #357 warm-connection work.
Route foreground/interactive fetches (message open) to a free/dedicated connection; let backfill use the other(s).
Measure cold-open latency (p50/p95) A/B — pool (2–3) vs single — via the scripts/device-testing harness with logcat + AppLog breadcrumbs, against:
Gmail (the throttled/slow case from the drilldown), and
Outlook as a fast-provider control.
Confirm no provider connection-limit violations during the runs.
Constraints / risks
Respect per-provider connection caps — coordinate with #361 (Gmail), #362 (Yahoo/AOL — low limit + 1-hour auth-lockout risk, cap most conservatively), #363 (iCloud). Keeping the pool small (2–3) is precisely to stay well under caps.
Must not regress backfill throughput materially.
Interacts with #355: if a dedicated interactive connection is sufficient, #355's pause may become unnecessary or purely complementary — the spike should explicitly note the interaction and recommend which lever(s) to keep.
Deliverables (acceptance criteria)
Bounded connection pool (2–3) prototype behind a dev flag, building on #357.
A/B cold-open latency data (p50/p95, pool vs single) on Gmail + Outlook, captured via scripts/device-testing.
Provider-limit safety check (no connection-cap errors / lockouts observed).
Written recommendation: does 2–3 connections help enough to productize? How does it interact with #355? File follow-up implementation ticket(s) if yes.
Relates
#357 (connection reuse), #355 (pause backfill on open), #360 / #361 / #362 / #363 (throttling + per-provider limits), #358 (reader-path instrumentation), and the message-open perf drilldown.
## Context
The message-open perf drilldown traced slow **user-tapped cold opens** to IMAP contention: with effectively one working connection, an interactive fetch queues behind background backfill, and Gmail additionally throttles connect-per-op (Gmail cold opens measured 31–40s vs Outlook 2–3s). Two levers already exist/are in flight: **#357** landed connection **reuse** (warm connection), and **#355** (in flight) **pauses** backfill during an open. This spike explores the orthogonal lever: a **small connection pool (2–3)** so an interactive cold open runs on its *own* connection rather than waiting on — or having to pause — backfill.
## Goal
Determine, with real measurements, whether a small number of concurrent IMAP connections (**2–3**) meaningfully improves user-tapped cold-open latency vs today's single-connection model — **without** tripping per-provider connection limits or regressing backfill throughput. This is a **spike**: deliverable is a prototype + data + a ship/no-ship recommendation, not production-hardened code.
## Approach
1. Prototype a **bounded IMAP connection pool** (size configurable, default 2–3) behind a **dev flag**, building on the #357 warm-connection work.
2. Route foreground/interactive fetches (message open) to a free/dedicated connection; let backfill use the other(s).
3. Measure cold-open latency (**p50/p95**) A/B — pool (2–3) vs single — via the `scripts/device-testing` harness with logcat + AppLog breadcrumbs, against:
- **Gmail** (the throttled/slow case from the drilldown), and
- **Outlook** as a fast-provider control.
4. Confirm no provider connection-limit violations during the runs.
## Constraints / risks
- **Respect per-provider connection caps** — coordinate with #361 (Gmail), #362 (Yahoo/AOL — low limit + **1-hour auth-lockout** risk, cap most conservatively), #363 (iCloud). Keeping the pool small (2–3) is precisely to stay well under caps.
- Must **not regress backfill throughput** materially.
- **Interacts with #355**: if a dedicated interactive connection is sufficient, #355's pause may become unnecessary or purely complementary — the spike should explicitly note the interaction and recommend which lever(s) to keep.
## Deliverables (acceptance criteria)
- [ ] Bounded connection pool (2–3) prototype behind a dev flag, building on #357.
- [ ] A/B cold-open latency data (p50/p95, pool vs single) on Gmail + Outlook, captured via `scripts/device-testing`.
- [ ] Provider-limit safety check (no connection-cap errors / lockouts observed).
- [ ] Written recommendation: does 2–3 connections help enough to productize? How does it interact with #355? File follow-up implementation ticket(s) if yes.
## Relates
#357 (connection reuse), #355 (pause backfill on open), #360 / #361 / #362 / #363 (throttling + per-provider limits), #358 (reader-path instrumentation), and the message-open perf drilldown.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Context
The message-open perf drilldown traced slow user-tapped cold opens to IMAP contention: with effectively one working connection, an interactive fetch queues behind background backfill, and Gmail additionally throttles connect-per-op (Gmail cold opens measured 31–40s vs Outlook 2–3s). Two levers already exist/are in flight: #357 landed connection reuse (warm connection), and #355 (in flight) pauses backfill during an open. This spike explores the orthogonal lever: a small connection pool (2–3) so an interactive cold open runs on its own connection rather than waiting on — or having to pause — backfill.
Goal
Determine, with real measurements, whether a small number of concurrent IMAP connections (2–3) meaningfully improves user-tapped cold-open latency vs today's single-connection model — without tripping per-provider connection limits or regressing backfill throughput. This is a spike: deliverable is a prototype + data + a ship/no-ship recommendation, not production-hardened code.
Approach
scripts/device-testingharness with logcat + AppLog breadcrumbs, against:Constraints / risks
Deliverables (acceptance criteria)
scripts/device-testing.Relates
#357 (connection reuse), #355 (pause backfill on open), #360 / #361 / #362 / #363 (throttling + per-provider limits), #358 (reader-path instrumentation), and the message-open perf drilldown.