Andrea Cosentino created CAMEL-26581:
----------------------------------------
Summary: camel-google-calendar - follow all pages in stream polling
Key: CAMEL-26581
URL: https://issues.apache.org/jira/browse/CAMEL-26581
Project: Camel
Issue Type: Bug
Components: camel-google-calendar
Reporter: Andrea Cosentino
`components/camel-google/camel-google-calendar/src/main/java/org/apache/camel/component/google/calendar/stream/GoogleCalendarStreamConsumer.java:143`
```java
c = request.setOrderBy("updated").execute();
```
The non-sync branch never reads or follows nextPageToken. It sets updatedMin
from the previous cursor (lines 91–94), then filters already-delivered boundary
events (210–213). With syncFlow=false, considerLastUpdate=true,
consumeFromNow=false, maxResults=1, a first page containing event A at T can be
returned repeatedly, while event B remains on a later page. A is suppressed
locally and the cursor never progresses. A full page of events sharing a
timestamp can produce the same problem with larger page sizes. Follow every
page before completing the polling window, preserving the same-time
deduplication.
History: CAMEL-24343 / ab77bb5ee23b intentionally fixed cursor advancement and
deduplication; pagination must complement that fix, not revert it. Existing
cursor tests supply complete lists, missing request-level pagination.
[Google API
reference](https://developers.google.com/workspace/calendar/api/v3/reference/events/list)
confirms ascending updated ordering, page-size limits and nextPageToken.
Expected behavior: the operation honors its documented contract, including
exceptional and terminal paths. Add regression tests for the triggering case
described above.
Audited against upstream main 3658e02a7f9d. AI-generated by Codex on behalf of
oscerd (JIRA acosentino).
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
