Summary
checkForPollingChanges (src/polling.ts) reads a single 100-entry sync chunk and then force-advances its cursor to the current updateCount:
const chunk = await evernoteApi.getFilteredSyncChunk(lastUpdateCount, maxEntries /* 100 */, buildSyncChunkFilter());
return { changes: changesFromSyncChunk(chunk, now), currentUpdateCount, nextUpdateCount: currentUpdateCount };If more than maxEntries (100) changes occurred since the last poll, every change past the first 100 in that USN range is silently dropped — the cursor jumps to currentUpdateCount without those entries ever being surfaced as webhook notifications.
Impact
- Webhook consumers miss change notifications during bursts of >100 edits between polls (e.g. a bulk import/edit, or a long poll interval).
- Tolerable-ish for best-effort webhooks, but it's a real correctness gap.
Context
The USN-keyed note body cache added in #60 (src/note-cache.ts) deliberately does not reuse this path for exactly this reason — it runs its own looped getFilteredSyncChunk walk that paginates on chunkHighUSN until it reaches updateCount, so it never truncates. That loop is the reference implementation for fixing polling here.
Proposed fix
Loop getFilteredSyncChunk in checkForPollingChanges (paginate on chunkHighUSN until >= currentUpdateCount, with a sane iteration cap) instead of reading one chunk and force-advancing. Reuse the pagination shape from NoteCache in src/note-cache.ts. Extend __tests__/unit/polling.test.ts with a multi-chunk (>100 change) case.
Filed as a follow-up from #60.
Summary
checkForPollingChanges(src/polling.ts) reads a single 100-entry sync chunk and then force-advances its cursor to the currentupdateCount:If more than
maxEntries(100) changes occurred since the last poll, every change past the first 100 in that USN range is silently dropped — the cursor jumps tocurrentUpdateCountwithout those entries ever being surfaced as webhook notifications.Impact
Context
The USN-keyed note body cache added in #60 (
src/note-cache.ts) deliberately does not reuse this path for exactly this reason — it runs its own loopedgetFilteredSyncChunkwalk that paginates onchunkHighUSNuntil it reachesupdateCount, so it never truncates. That loop is the reference implementation for fixing polling here.Proposed fix
Loop
getFilteredSyncChunkincheckForPollingChanges(paginate onchunkHighUSNuntil>= currentUpdateCount, with a sane iteration cap) instead of reading one chunk and force-advancing. Reuse the pagination shape fromNoteCacheinsrc/note-cache.ts. Extend__tests__/unit/polling.test.tswith a multi-chunk (>100 change) case.Filed as a follow-up from #60.