Skip to content

fix(sidecar): resume Gmail history past page cap when pages are deduped - #689

Closed
cursor[bot] wants to merge 2 commits into
mainfrom
cursor/critical-bug-investigation-806b
Closed

cursor[bot] wants to merge 2 commits into
mainfrom
cursor/critical-bug-investigation-806b

Conversation

@cursor

@cursor cursor Bot commented Aug 20, 2026

Copy link
Copy Markdown

Summary

  • Persist history_page_token in sidecar_state (migration 32) when Gmail history listing hits the 3-page cap with more pages pending
  • Resume listNewMessageIds from the saved page token on the next poll instead of re-fetching pages 1–3 from the frozen cursor
  • Clear the resume token when the listing completes or on history-gap re-anchor

Why

When a sidecar mailbox receives a burst of mail spanning more than 3 Gmail history pages, listNewMessageIds returns truncated: true and the cursor correctly stays frozen. If pages 1–3 are fully deduped on every poll, the poller never advances to page 4+ — silent mail loss for tail messages until the cursor expires into a history-gap re-anchor.

Concrete trigger: burst >3 history pages where early pages are already ingested; each poll re-lists pages 1–3 (all deduped), cursor never moves, page 4+ never fetched.

Test plan

  • npm test passes locally (60 targeted: workspace-poll, gmail-client, sidecar-state)
  • New regression: two-poll convergence when pages 1–3 deduped and page 4 has fresh mail
  • listNewMessageIds resume-from-pageToken unit test
  • npm run typecheck (not run — sidecar-only change)

Notes for reviewer

Cherry-pick of validated fix from prior critical-bug scans (#667). Same root cause as #607’s truncated-cursor guard; this closes the dedupe wedge where frozen cursor + re-fetch never reaches the tail.

Open in Web View Automation 

cursoragent and others added 2 commits August 20, 2026 11:02
…ed (#667)

When Gmail history spans more than MAX_HISTORY_PAGES (3) and pages 1–3 are
fully deduped, truncated=true froze the cursor forever and page 4+ messages
were never ingested — silent data loss during mail bursts.

Persist history_page_token in sidecar_state (migration 32) and pass it to
listNewMessageIds so the next poll resumes from the dangling pageToken
instead of re-fetching already-deduped pages.

Co-authored-by: schmug <schmug@users.noreply.github.com>
…nit test

Complements #667 cherry-pick: first truncated-history poll test now checks
the persisted page token, and gmail-client gets a resumePageToken test.

Co-authored-by: schmug <schmug@users.noreply.github.com>
@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying with  Cloudflare Workers  Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status Name Latest Commit Preview URL Updated (UTC)
✅ Deployment successful!
View logs
ais-hub 9665ef6 Commit Preview URL

Branch Preview URL
Aug 20 2026, 11:03 AM

@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying with  Cloudflare Workers  Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status Name Latest Commit Updated (UTC)
✅ Deployment successful!
View logs
agentic-inbox 9665ef6 Aug 20 2026, 11:04 AM

@schmug

schmug commented Aug 23, 2026

Copy link
Copy Markdown
Owner

Closing as superseded by #686.

This is one of 24 near-identical PRs re-filed daily by an automation that has since been fixed. #686 carries the same Gmail history page-token change and is the one kept open, so no work is lost here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants