Repository navigation
fix: follow the decreasing event sync cursor and never return partial lists - #48
Conversation
… lists The events sync endpoint returns the newest chunk first and reports the oldest updated_at of that chunk as the next cursor, so the cursor decreases. fetchEventPages stopped as soon as the cursor did not grow, which truncated get_events and list_memos after the first chunk in calendars with more than one chunk. Paging now continues while the cursor is new, in either direction. A repeated cursor or more than 200 pages raises an error instead of returning a partial list, and overlapping chunks keep one entry per event (the newest by updated_at). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7721f99edf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ## [Unreleased] | ||
|
|
||
| ### Fixed | ||
| - `get_events` and `list_memos` now read every event in large calendars. The events sync endpoint returns the newest chunk first with a decreasing cursor, and paging stopped after the first chunk. Paging now continues while the cursor is new, in either direction. |
There was a problem hiding this comment.
This announces a user-visible change to get_events and list_memos—including complete large-calendar results and new paging failures—but the commit leaves README.md, README.ko.md, README.ja.md, and COMMANDS.md unchanged. Add matching descriptions (including the shared pager's effect on get_updated_events) so every supported guide documents the new result and failure contract as required by the repository review rule.
AGENTS.md reference: AGENTS.md:L171-L171
Useful? React with 👍 / 👎.
|
Thank you for your contribution! |
2 participants
Pull Request
Description
get_eventsandlist_memosreturn only part of a calendar once it spans more than one sync chunk.The events sync endpoint (
/calendar/{id}/events/sync?since=) returns the newest chunk first and reports the oldestupdated_atof that chunk as the nextsince, so the cursor decreases from page to page.fetchEventPagesstopped as soon as the cursor did not grow (validated.since <= cursor), which ends paging after the first chunk.Observed with a personal account on an earlier version with a similar stop condition (counts only): a calendar with about 2,300 events and one with about 680 both came back with 600 events. Callers that compare listings, such as sync tools, read the missing events as deleted.
Type of Change
Related Issue
None filed; this PR describes the problem.
Changes Made
getUpdatedEventskeeps working.uuid, the newest byupdated_at.Testing
npm run typecheck,npm test(68 tests pass), andnpm audit --audit-level=highpass, run as separate stepsTest Environment
Documentation
[Unreleased]Checklist
Breaking Changes
None for valid responses. Responses that previously ended in a silently truncated list now raise an error.
Additional Notes
The cursor semantics come from observed behavior of an undocumented API. Allowing either direction instead of assuming a decreasing cursor keeps both endpoints working if TimeTree changes the order.
🤖 Generated with Claude Code