notion sync: internal /search endpoint caps results, blocks reliable backfill

[tenfourty]

Symptom

kbx sync notion against the internal Notion API (notion.so/api/v3/search) returns a hard server-side cap on results. Pagination loop in kb/sync/notion.py:670-694 follows the paginationToken from each response, but the API stops returning new pages well before all matching results are covered. Resulting backfills miss meetings silently.

Observed: multiple httpx.HTTPStatusError: 502 Bad Gateway and truncated result sets when running larger --since windows. After ~100 results across pages, syncs return either 502 or empty.

Current state

Disabled in cron on 2026-05-18 (scripts/kb-sync-cron.sh:46-52, in consumer repo) pending a fix. CLI command kbx sync notion still exists and is callable, but unsafe for unattended runs.

Why it's broken

Notion's internal /search endpoint (used by the web app for typeahead) is not designed as a backfill/export API. It:

• Caps results server-side regardless of paginationToken
• Returns 502s under any load that resembles bulk pagination
• Has no documented contract — could change without notice

Fix options

1. Move to official Notion API (https://api.notion.com/v1/search): documented pagination via next_cursor, OAuth + integration token auth, predictable rate limits (3 req/sec). Requires installing a Notion integration in the workspace and switching auth model.
2. Patch the internal /search call: switch payload type from BlocksInSpace to a narrower query, batch by date range slices (e.g., 7-day windows) instead of relying on pagination. Stopgap only.

Affected code

• src/kb/sync/notion.py:203-249 — Client.search_pages
• src/kb/sync/notion.py:670-694 — pagination loop in sync_notion
• CLI: kbx sync notion

Acceptance

• kbx sync notion --since <30d ago> completes without 502 and returns the same set of pages a human would see in the workspace
• Re-enable in consumer cron

---

Restored from prior issue #109 after repository history rewrite (PII remediation, 2026-05-27).

[tenfourty]

Parking — Notion deprecated as a meeting source

Notion is no longer used as a meeting-notes source: Granola has fully taken over. Current index split is ~1970 Granola notes vs ~159 Notion notes, with the Notion notes all pre-April — i.e. the Notion side has been inert for months. Confirmed that meeting capture has moved off Notion entirely.

Given that, the ~2-day migration to the official Notion API (api.notion.com/v1/search) isn't worth it right now — we'd be fixing a backfill path for a source that no longer receives new content. The sync command stays disabled in the consumer cron (where it was parked on 2026-05-18), which is the safe state.

Decision: park as backlog/Someday. Leaving the issue open as a documented record of the limitation and the fix path. If Notion-sourced meetings resume, the official-API migration (documented next_cursor pagination + integration-token auth, same Keychain pattern as Granola) is the route to revive it — the diagnosis and affected code (sync/notion.py) are already captured above.

(No someday/backlog label in this repo's label set, so this comment is the marker.)