fix(gmail): bound incremental sync per pass to stop isolate OOM

[KrisBraun]

Problem

The mailbox-wide Gmail incremental sync drained the entire changed-thread set of a history window in a single isolate pass — syncGmailMailboxIncremental collected every changed thread id and getThread()'d all of them into one in-memory array (the comment even said "a single pass drains the whole history window").

For a large window — the history-cursor reseed after the 2026-06-25 Google composite re-home, or a high-volume burst — this loaded hundreds of full threads at once and exceeded the Cloudflare Worker memory limit (Worker exceeded memory limit., PostHog issue 019ed581).

The OOM killed the isolate mid-save: the API worker's request-scoped Kysely connection was torn down in its finally while in-flight saveLink/createLink work was still querying it, surfacing as driver has already been destroyed (PostHog 019f1398 / 019f1399) and dropping mail. The fetch storm also tripped Gmail's per-minute API quota (403s).

Evidence

For the affected user's connector, the per-user error timeline interleaves Worker exceeded memory limit. (bursts of 8–9), Gmail 403 Quota exceeded … Queries per minute per user, and driver has already been destroyed — the driver errors land immediately after each OOM burst.

Fix

Bound each incremental pass to MAX_INCREMENTAL_THREADS_PER_BATCH = 20 (matching the proven-safe initial-backfill page size):

• syncGmailMailboxIncremental fetches at most the cap and returns the overflow as deferredThreadIds. retryThreadIds are inserted first, so prior backlog drains ahead of newly-changed threads.
• mergePendingThreads(prior, failed, deferred?) carries deferred ids forward without bumping the failed-fetch attempt counter — they were postponed, not tried — so a large backlog drains instead of being abandoned.
• incrementalSyncBatchFn + the self-heal path carry deferred ids in pendingThreadIds and schedule a self-terminating continuation via the existing queueIncrementalSync scheduler hook (exit condition: nothing deferred; failed-only does not re-queue, so a permanently-unfetchable thread can't hot-loop).

No connector-class changes — the composite Google connector inherits the fix through the same shared functions.

Tests

• New gmail-incremental-bound.test.ts (8 tests): per-pass cap + deferral, retry-id ordering, back-compat (unbounded when maxThreads omitted), deferred-carry without attempt bump, failed-vs-deferred distinction, and the incrementalSyncBatchFn cap + cursor-advance + continuation wiring.
• Full suites pass: gmail (63), google (64). tsc + plot lint clean.

Connector-only change → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

The mailbox-wide Gmail incremental sync drained the entire changed-thread set of a history window in a single isolate pass — syncGmailMailboxIncremental collected every changed thread id and getThread()'d all of them into one in-memory array (the comment even said "a single pass drains the whole history window").

For a large window — the history-cursor reseed after the 2026-06-25 Google composite re-home, or a high-volume burst — this loaded hundreds of full threads at once and exceeded the Cloudflare Worker memory limit (Worker exceeded memory limit., PostHog issue 019ed581).

The OOM killed the isolate mid-save: the API worker's request-scoped Kysely connection was torn down in its finally while in-flight saveLink/createLink work was still querying it, surfacing as driver has already been destroyed (PostHog 019f1398 / 019f1399) and dropping mail. The fetch storm also tripped Gmail's per-minute API quota (403s).

Evidence

For the affected user's connector, the per-user error timeline interleaves Worker exceeded memory limit. (bursts of 8–9), Gmail 403 Quota exceeded … Queries per minute per user, and driver has already been destroyed — the driver errors land immediately after each OOM burst.

Fix

Bound each incremental pass to MAX_INCREMENTAL_THREADS_PER_BATCH = 20 (matching the proven-safe initial-backfill page size):

• syncGmailMailboxIncremental fetches at most the cap and returns the overflow as deferredThreadIds. retryThreadIds are inserted first, so prior backlog drains ahead of newly-changed threads.
• mergePendingThreads(prior, failed, deferred?) carries deferred ids forward without bumping the failed-fetch attempt counter — they were postponed, not tried — so a large backlog drains instead of being abandoned.
• incrementalSyncBatchFn + the self-heal path carry deferred ids in pendingThreadIds and schedule a self-terminating continuation via the existing queueIncrementalSync scheduler hook (exit condition: nothing deferred; failed-only does not re-queue, so a permanently-unfetchable thread can't hot-loop).

No connector-class changes — the composite Google connector inherits the fix through the same shared functions.

Tests

• New gmail-incremental-bound.test.ts (8 tests): per-pass cap + deferral, retry-id ordering, back-compat (unbounded when maxThreads omitted), deferred-carry without attempt bump, failed-vs-deferred distinction, and the incrementalSyncBatchFn cap + cursor-advance + continuation wiring.
• Full suites pass: gmail (63), google (64). tsc + plot lint clean.

Connector-only change → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

The mailbox-wide Gmail incremental sync drained the entire changed-thread set of a history window in a single isolate pass — syncGmailMailboxIncremental collected every changed thread id and getThread()'d all of them into one in-memory array (the comment even said "a single pass drains the whole history window").

For a large window — the history-cursor reseed after the 2026-06-25 Google composite re-home, or a high-volume burst — this loaded hundreds of full threads at once and exceeded the Cloudflare Worker memory limit (Worker exceeded memory limit., PostHog issue 019ed581).

The OOM killed the isolate mid-save: the API worker's request-scoped Kysely connection was torn down in its finally while in-flight saveLink/createLink work was still querying it, surfacing as driver has already been destroyed (PostHog 019f1398 / 019f1399) and dropping mail. The fetch storm also tripped Gmail's per-minute API quota (403s).

Evidence

For the affected user's connector, the per-user error timeline interleaves Worker exceeded memory limit. (bursts of 8–9), Gmail 403 Quota exceeded … Queries per minute per user, and driver has already been destroyed — the driver errors land immediately after each OOM burst.

Fix

Bound each incremental pass to MAX_INCREMENTAL_THREADS_PER_BATCH = 20 (matching the proven-safe initial-backfill page size):

• syncGmailMailboxIncremental fetches at most the cap and returns the overflow as deferredThreadIds. retryThreadIds are inserted first, so prior backlog drains ahead of newly-changed threads.
• mergePendingThreads(prior, failed, deferred?) carries deferred ids forward without bumping the failed-fetch attempt counter — they were postponed, not tried — so a large backlog drains instead of being abandoned.
• incrementalSyncBatchFn + the self-heal path carry deferred ids in pendingThreadIds and schedule a self-terminating continuation via the existing queueIncrementalSync scheduler hook (exit condition: nothing deferred; failed-only does not re-queue, so a permanently-unfetchable thread can't hot-loop).

No connector-class changes — the composite Google connector inherits the fix through the same shared functions.

Tests

• New gmail-incremental-bound.test.ts (8 tests): per-pass cap + deferral, retry-id ordering, back-compat (unbounded when maxThreads omitted), deferred-carry without attempt bump, failed-vs-deferred distinction, and the incrementalSyncBatchFn cap + cursor-advance + continuation wiring.
• Full suites pass: gmail (63), google (64). tsc + plot lint clean.

Connector-only change → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

The mailbox-wide Gmail incremental sync drained the entire changed-thread set of a history window in a single isolate pass — syncGmailMailboxIncremental collected every changed thread id and getThread()'d all of them into one in-memory array (the comment even said "a single pass drains the whole history window").

For a large window — the history-cursor reseed after the 2026-06-25 Google composite re-home, or a high-volume burst — this loaded hundreds of full threads at once and exceeded the Cloudflare Worker memory limit (Worker exceeded memory limit., PostHog issue 019ed581).

The OOM killed the isolate mid-save: the API worker's request-scoped Kysely connection was torn down in its finally while in-flight saveLink/createLink work was still querying it, surfacing as driver has already been destroyed (PostHog 019f1398 / 019f1399) and dropping mail. The fetch storm also tripped Gmail's per-minute API quota (403s).

Evidence

For the affected user's connector, the per-user error timeline interleaves Worker exceeded memory limit. (bursts of 8–9), Gmail 403 Quota exceeded … Queries per minute per user, and driver has already been destroyed — the driver errors land immediately after each OOM burst.

Fix

Bound each incremental pass to MAX_INCREMENTAL_THREADS_PER_BATCH = 20 (matching the proven-safe initial-backfill page size):

• syncGmailMailboxIncremental fetches at most the cap and returns the overflow as deferredThreadIds. retryThreadIds are inserted first, so prior backlog drains ahead of newly-changed threads.
• mergePendingThreads(prior, failed, deferred?) carries deferred ids forward without bumping the failed-fetch attempt counter — they were postponed, not tried — so a large backlog drains instead of being abandoned.
• incrementalSyncBatchFn + the self-heal path carry deferred ids in pendingThreadIds and schedule a self-terminating continuation via the existing queueIncrementalSync scheduler hook (exit condition: nothing deferred; failed-only does not re-queue, so a permanently-unfetchable thread can't hot-loop).

No connector-class changes — the composite Google connector inherits the fix through the same shared functions.

Tests

• New gmail-incremental-bound.test.ts (8 tests): per-pass cap + deferral, retry-id ordering, back-compat (unbounded when maxThreads omitted), deferred-carry without attempt bump, failed-vs-deferred distinction, and the incrementalSyncBatchFn cap + cursor-advance + continuation wiring.
• Full suites pass: gmail (63), google (64). tsc + plot lint clean.

Connector-only change → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

The mailbox-wide Gmail incremental sync drained the entire changed-thread set of a history window in a single isolate pass — syncGmailMailboxIncremental collected every changed thread id and getThread()'d all of them into one in-memory array (the comment even said "a single pass drains the whole history window").

For a large window — the history-cursor reseed after the 2026-06-25 Google composite re-home, or a high-volume burst — this loaded hundreds of full threads at once and exceeded the Cloudflare Worker memory limit (Worker exceeded memory limit., PostHog issue 019ed581).

The OOM killed the isolate mid-save: the API worker's request-scoped Kysely connection was torn down in its finally while in-flight saveLink/createLink work was still querying it, surfacing as driver has already been destroyed (PostHog 019f1398 / 019f1399) and dropping mail. The fetch storm also tripped Gmail's per-minute API quota (403s).

Evidence

For the affected user's connector, the per-user error timeline interleaves Worker exceeded memory limit. (bursts of 8–9), Gmail 403 Quota exceeded … Queries per minute per user, and driver has already been destroyed — the driver errors land immediately after each OOM burst.

Fix

Bound each incremental pass to MAX_INCREMENTAL_THREADS_PER_BATCH = 20 (matching the proven-safe initial-backfill page size):

• syncGmailMailboxIncremental fetches at most the cap and returns the overflow as deferredThreadIds. retryThreadIds are inserted first, so prior backlog drains ahead of newly-changed threads.
• mergePendingThreads(prior, failed, deferred?) carries deferred ids forward without bumping the failed-fetch attempt counter — they were postponed, not tried — so a large backlog drains instead of being abandoned.
• incrementalSyncBatchFn + the self-heal path carry deferred ids in pendingThreadIds and schedule a self-terminating continuation via the existing queueIncrementalSync scheduler hook (exit condition: nothing deferred; failed-only does not re-queue, so a permanently-unfetchable thread can't hot-loop).

No connector-class changes — the composite Google connector inherits the fix through the same shared functions.

Tests

• New gmail-incremental-bound.test.ts (8 tests): per-pass cap + deferral, retry-id ordering, back-compat (unbounded when maxThreads omitted), deferred-carry without attempt bump, failed-vs-deferred distinction, and the incrementalSyncBatchFn cap + cursor-advance + continuation wiring.
• Full suites pass: gmail (63), google (64). tsc + plot lint clean.

Connector-only change → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

The mailbox-wide Gmail incremental sync drained the entire changed-thread set of a history window in a single isolate pass — syncGmailMailboxIncremental collected every changed thread id and getThread()'d all of them into one in-memory array (the comment even said "a single pass drains the whole history window").

For a large window — the history-cursor reseed after the 2026-06-25 Google composite re-home, or a high-volume burst — this loaded hundreds of full threads at once and exceeded the Cloudflare Worker memory limit (Worker exceeded memory limit., PostHog issue 019ed581).

The OOM killed the isolate mid-save: the API worker's request-scoped Kysely connection was torn down in its finally while in-flight saveLink/createLink work was still querying it, surfacing as driver has already been destroyed (PostHog 019f1398 / 019f1399) and dropping mail. The fetch storm also tripped Gmail's per-minute API quota (403s).

Evidence

For the affected user's connector, the per-user error timeline interleaves Worker exceeded memory limit. (bursts of 8–9), Gmail 403 Quota exceeded … Queries per minute per user, and driver has already been destroyed — the driver errors land immediately after each OOM burst.

Fix

Bound each incremental pass to MAX_INCREMENTAL_THREADS_PER_BATCH = 20 (matching the proven-safe initial-backfill page size):

• syncGmailMailboxIncremental fetches at most the cap and returns the overflow as deferredThreadIds. retryThreadIds are inserted first, so prior backlog drains ahead of newly-changed threads.
• mergePendingThreads(prior, failed, deferred?) carries deferred ids forward without bumping the failed-fetch attempt counter — they were postponed, not tried — so a large backlog drains instead of being abandoned.
• incrementalSyncBatchFn + the self-heal path carry deferred ids in pendingThreadIds and schedule a self-terminating continuation via the existing queueIncrementalSync scheduler hook (exit condition: nothing deferred; failed-only does not re-queue, so a permanently-unfetchable thread can't hot-loop).

No connector-class changes — the composite Google connector inherits the fix through the same shared functions.

Tests

• New gmail-incremental-bound.test.ts (8 tests): per-pass cap + deferral, retry-id ordering, back-compat (unbounded when maxThreads omitted), deferred-carry without attempt bump, failed-vs-deferred distinction, and the incrementalSyncBatchFn cap + cursor-advance + continuation wiring.
• Full suites pass: gmail (63), google (64). tsc + plot lint clean.

Connector-only change → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

The mailbox-wide Gmail incremental sync drained the entire changed-thread set of a history window in a single isolate pass — syncGmailMailboxIncremental collected every changed thread id and getThread()'d all of them into one in-memory array (the comment even said "a single pass drains the whole history window").

For a large window — the history-cursor reseed after the 2026-06-25 Google composite re-home, or a high-volume burst — this loaded hundreds of full threads at once and exceeded the Cloudflare Worker memory limit (Worker exceeded memory limit., PostHog issue 019ed581).

The OOM killed the isolate mid-save: the API worker's request-scoped Kysely connection was torn down in its finally while in-flight saveLink/createLink work was still querying it, surfacing as driver has already been destroyed (PostHog 019f1398 / 019f1399) and dropping mail. The fetch storm also tripped Gmail's per-minute API quota (403s).

Evidence

For the affected user's connector, the per-user error timeline interleaves Worker exceeded memory limit. (bursts of 8–9), Gmail 403 Quota exceeded … Queries per minute per user, and driver has already been destroyed — the driver errors land immediately after each OOM burst.

Fix

Bound each incremental pass to MAX_INCREMENTAL_THREADS_PER_BATCH = 20 (matching the proven-safe initial-backfill page size):

• syncGmailMailboxIncremental fetches at most the cap and returns the overflow as deferredThreadIds. retryThreadIds are inserted first, so prior backlog drains ahead of newly-changed threads.
• mergePendingThreads(prior, failed, deferred?) carries deferred ids forward without bumping the failed-fetch attempt counter — they were postponed, not tried — so a large backlog drains instead of being abandoned.
• incrementalSyncBatchFn + the self-heal path carry deferred ids in pendingThreadIds and schedule a self-terminating continuation via the existing queueIncrementalSync scheduler hook (exit condition: nothing deferred; failed-only does not re-queue, so a permanently-unfetchable thread can't hot-loop).

No connector-class changes — the composite Google connector inherits the fix through the same shared functions.

Tests

• New gmail-incremental-bound.test.ts (8 tests): per-pass cap + deferral, retry-id ordering, back-compat (unbounded when maxThreads omitted), deferred-carry without attempt bump, failed-vs-deferred distinction, and the incrementalSyncBatchFn cap + cursor-advance + continuation wiring.
• Full suites pass: gmail (63), google (64). tsc + plot lint clean.

Connector-only change → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

The mailbox-wide Gmail incremental sync drained the entire changed-thread set of a history window in a single isolate pass — syncGmailMailboxIncremental collected every changed thread id and getThread()'d all of them into one in-memory array (the comment even said "a single pass drains the whole history window").

For a large window — the history-cursor reseed after the 2026-06-25 Google composite re-home, or a high-volume burst — this loaded hundreds of full threads at once and exceeded the Cloudflare Worker memory limit (Worker exceeded memory limit., PostHog issue 019ed581).

The OOM killed the isolate mid-save: the API worker's request-scoped Kysely connection was torn down in its finally while in-flight saveLink/createLink work was still querying it, surfacing as driver has already been destroyed (PostHog 019f1398 / 019f1399) and dropping mail. The fetch storm also tripped Gmail's per-minute API quota (403s).

Evidence

For the affected user's connector, the per-user error timeline interleaves Worker exceeded memory limit. (bursts of 8–9), Gmail 403 Quota exceeded … Queries per minute per user, and driver has already been destroyed — the driver errors land immediately after each OOM burst.

Fix

Bound each incremental pass to MAX_INCREMENTAL_THREADS_PER_BATCH = 20 (matching the proven-safe initial-backfill page size):

• syncGmailMailboxIncremental fetches at most the cap and returns the overflow as deferredThreadIds. retryThreadIds are inserted first, so prior backlog drains ahead of newly-changed threads.
• mergePendingThreads(prior, failed, deferred?) carries deferred ids forward without bumping the failed-fetch attempt counter — they were postponed, not tried — so a large backlog drains instead of being abandoned.
• incrementalSyncBatchFn + the self-heal path carry deferred ids in pendingThreadIds and schedule a self-terminating continuation via the existing queueIncrementalSync scheduler hook (exit condition: nothing deferred; failed-only does not re-queue, so a permanently-unfetchable thread can't hot-loop).

No connector-class changes — the composite Google connector inherits the fix through the same shared functions.

Tests

• New gmail-incremental-bound.test.ts (8 tests): per-pass cap + deferral, retry-id ordering, back-compat (unbounded when maxThreads omitted), deferred-carry without attempt bump, failed-vs-deferred distinction, and the incrementalSyncBatchFn cap + cursor-advance + continuation wiring.
• Full suites pass: gmail (63), google (64). tsc + plot lint clean.

Connector-only change → no changeset.

🤖 Generated with Claude Code