[jira] [Updated] (CAMEL-25576) camel-box - event-logs/getEnterpriseEvents returns only the first chunk of the event log (at most 500 events); the events after it are dropped silently and cannot be requested

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-25576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-25576:
--------------------------------
    Fix Version/s: 4.24.0

> camel-box - event-logs/getEnterpriseEvents returns only the first chunk of the event log (at most 500 events); the events after it are dropped silently and cannot be requested
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25576
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25576
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-box
>            Reporter: shashank
>            Assignee: shashank
>            Priority: Major
>             Fix For: 4.24.0
>
>
> {{BoxEventLogsManager.getEnterpriseEvents}} (lines 68-96 at main c3829069cb72), the only method of the {{box:event-logs}} API:
> {code:java}
> EnterpriseEventsRequest request = new EnterpriseEventsRequest();
> request.position(position).after(after).before(before).types(types);
> EventLog eventLog = EventLog.getEnterpriseEvents(boxConnection, request);
> List<BoxEvent> results = new ArrayList<>();
> for (BoxEvent event : eventLog) {
>     results.add(event);
> }
> return results;
> {code}
> An {{EventLog}} of box-java-sdk 4.16.4 is one response of the events endpoint: {{EnterpriseEventsRequest}} asks for {{limit = 500}} (the constant in its constructor), and the response has the events of that chunk and {{getNextStreamPosition()}} for the next one. The manager sends one request and returns the events of that response. It does not read the next stream position and does not return it either (the result is a plain {{List<BoxEvent>}}).
> So when more than 500 events lie between {{after}} and {{before}}, the caller gets the first 500 and has no means to ask for the rest: the {{position}} parameter needs a stream position, which only the dropped {{EventLog}} had. Nothing is logged. The javadoc of the method says "@return A list of all the events that met the given criteria", and for {{position}}: "May be null in which case all events within bounds returned".
> h3. Reproduction
> New {{BoxEventLogsManagerPagingTest}} (3 tests) in camel-box-component. A real {{BoxAPIConnection}} gets a {{RequestInterceptor}} that answers the events request from memory like the service: at most 500 events from the requested {{stream_position}}, and {{next_stream_position}} (the fake fails the test after 20 requests). So the SDK parses real responses. On main all 3 fail:
> * {{returnsTheEventsOfEveryChunk}} (1200 events): {{all the events within bounds, not only the first chunk ==> expected: <1200> but was: <500>}}.
> * {{startsAtThePositionOfTheCallerAndReadsToTheEnd}} (position 100 of 1200): 1100 events expected, 500 returned.
> * {{stopsWhenTheServiceDoesNotMoveThePosition}}: {{expected: <2> but was: <1>}} (requests; it checks that the new loop ends when a response repeats the position it was asked for, and that events returned twice are kept once).
> h3. Proposed fix
> In {{BoxEventLogsManager.getEnterpriseEvents}}: read on from {{getNextStreamPosition()}} until a chunk is empty, which is the end of the events within bounds; also stop when the service returns no next position or the position it was asked for. The events are collected in a {{LinkedHashSet}} ({{BoxResource.equals}} compares the id), so an event that the service returns in two chunks is kept once and the order of the service is kept. The signature is unchanged; the javadoc of the return value now says that the log is read chunk by chunk and kept in memory.
> Behaviour change, with a 4.24 upgrade-guide entry: the operation returns all the events between {{after}} and {{before}}. Cost: one request per chunk of 500 events and one more that finds the end (two requests where main sent one, when everything fits in one chunk). A wide {{after}} / {{before}} window now returns every event in one list, with that many requests and more memory; the upgrade note and the javadoc say to narrow the window for a large event log. The loop has no limit of its own on the number of chunks: it ends on an empty chunk, on a missing next position or on a position that did not move. I end the loop on an empty chunk and not on a chunk shorter than the limit because I could not confirm from the SDK that a short chunk always means the end. camel-box-api and camel-box-component unit tests with the fix: 6, 0 failures (the integration tests need a Box account and were not run; nothing was run against Box).
> Found with a Lean 4 model of a position-paged service: the event log is a list, a response is a {{take}} / {{drop}} slice of it and the position after it. Property: the result is the log from the position of the caller to its end, every event once and in order. Counterexample for main: with chunks of two, {{[1, 2, 3]}} gives {{[1, 2]}} ({{cex_third_event_dropped}}); with a chunk of 500, 501 events give 500 ({{cex_501_events}}). In the model, reading chunk after chunk returns the list from the start position to its end ({{fix_meets_spec}}), and the same as main when the events fit in one chunk ({{fix_eq_main_one_chunk}}). The model says nothing about the real service. Then confirmed with the real class as described.
> Affected: main (4.23.0-SNAPSHOT at c3829069cb72), and the release branches camel-4.18.x (c3fd5317a5a0), camel-4.22.x (2821f284056c) and camel-4.23.x (197e70656a41): lines 66-95 of {{BoxEventLogsManager}} (the javadoc of the return value and the whole method body) are identical to main on all three. Read, not run.
> Duplicate check (2026-10-12): JIRA text "box getEnterpriseEvents" (none), "box enterprise events position" (2, unrelated: CAMEL-12998, CAMEL-12297); GitHub pull requests "box enterprise events": none; no open pull request touches camel-box.
> _Filed with Claude Code on behalf of allthingssecurity._



--
This message was sent by Atlassian Jira
(v8.20.10#820010)