bee sync fails: /v1/todos and /v1/daily return 500 immediately; /v1/facts 500s mid-pagination

[tylerbroome09-cloud]

Summary

bee sync (CLI v0.7.3, Windows x64, prod environment) fails on every run with:

Sync completed with 4 error(s):
  - Internal Server Error
  - Internal Server Error
  - Internal Server Error
  - Internal Server Error

I traced this to three distinct server-side issues on the prod API (app-api-developer.ce.bee.amazon.dev), verified by replaying the CLI's exact requests directly against the API (bypassing the CLI) via bee proxy.

Findings

1. GET /v1/todos returns HTTP 500 on the very first request (no cursor, no params).
Reproducible with bee todos list directly, not just bee sync.

$ curl .../v1/todos?limit=5
{"statusCode":500,"error":"Internal Server Error","message":"Internal Server Error"}

2. GET /v1/daily returns HTTP 500 on the very first request (no cursor, no params).
Reproducible with bee daily list directly.

$ curl .../v1/daily?limit=3
{"statusCode":500,"error":"Internal Server Error","message":"Internal Server Error"}

3. GET /v1/facts paginates successfully for the first 5 pages (limit=100), then returns 500 on page 6.
The failing request:

GET /v1/facts?limit=100&cursor=v1-1759379239528-6300413
-> {"statusCode":500,"error":"Internal Server Error","message":"Internal Server Error"}

That cursor corresponds to 2025-10-02T04:27:19.528Z, i.e. something in the batch of facts immediately older than that timestamp appears to break server-side serialization/query. Earlier pages (facts created after that date) all return 200 fine.

GET /v1/conversations works when listed directly (recent page), but since bee sync's conversations target also does a full historical walk similar to facts, it may hit an analogous deep-pagination issue in older data — untested since facts/todos/daily already accounted for the full error count.

Impact

Because bee sync runs facts/todos/daily/conversations concurrently and always does a full historical backfill for facts and todos (see below), there is no CLI flag that lets a user avoid the broken data — --recent-days and --since do not change behavior for the facts/todos targets at all, so every bee sync invocation attempts the full paginated walk and hits the 500 immediately or partway through.

Secondary bug: --recent-days/--since are ignored for facts and todos

Looking at sources/commands/sync/index.ts: syncFacts/fetchAllFacts and syncTodos/fetchAllTodos never receive or use options.recentDays/options.since/options.full — only the daily and conversations targets respect a bounded from date. So even bee sync --only facts --recent-days 1 still walks the entire history and hits the same 500.

Environment

• @beeai/cli 0.7.3, Windows x64
• bee status: prod environment, authenticated account
• Reproduced by extracting request paths from the bundled source in the compiled binary and replaying them via bee proxy (which forwards to the real prod API with the stored auth token), so this is confirmed server-side, not a Windows-specific or local filesystem issue.

Repro steps

bee login
bee sync
# -> "Sync completed with 4 error(s): Internal Server Error" x4

bee todos list --limit 5
# -> Internal Server Error

bee daily list --limit 3
# -> Internal Server Error