fix(api): use startIndex variable in downloadEventLog pagination loop#1114
fix(api): use startIndex variable in downloadEventLog pagination loop#1114sinchubhat wants to merge 1 commit into
Conversation
The function calculated and updated startIndex but passed 0 to GetEventLog, breaking pagination. Now passes startIndex and eventLogBatchSize properly. Fixes #1104
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1114 +/- ##
==========================================
+ Coverage 43.44% 43.54% +0.10%
==========================================
Files 143 143
Lines 13621 13621
==========================================
+ Hits 5917 5931 +14
+ Misses 7143 7126 -17
- Partials 561 564 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
Fixes v1 AMT event-log CSV download pagination by correctly using the computed startIndex and a non-zero batch size when repeatedly calling GetEventLog, so the download endpoint can retrieve all pages.
Changes:
- Add an
eventLogBatchSizeconstant and use it (withstartIndex) in thedownloadEventLogpagination loop. - Correct the loop termination condition to stop when
HasMoreRecordsis false. - Add a controller test to assert
downloadEventLogpaginates by advancingstartIndexbetween batches.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| internal/controller/httpapi/v1/auditlog.go | Fixes event-log download pagination to pass startIndex/batch size and stops when no more records are available. |
| internal/controller/httpapi/v1/auditlog_test.go | Adds a test validating that the download endpoint paginates via successive GetEventLog calls with increasing startIndex. |
Comments suppressed due to low confidence (1)
internal/controller/httpapi/v1/auditlog.go:136
- The pagination loop can spin indefinitely if the device returns an empty batch while still reporting
HasMoreRecords=true:startIndexwon’t advance (+= len(eventLogs.Records)), so the next iteration repeats the same request forever. Adding a defensive break on empty batches avoids a hung download endpoint.
// Break when no more records are available from AMT.
if !eventLogs.HasMoreRecords {
break
}
// Update the startIndex for the next batch
startIndex += len(eventLogs.Records)
|
@sinchubhat : could you please capture the results without this PR fix and share the observations for the manual test you have done. |
It does show all the event logs, but gets stuck if we click the download button. Even the curl cmd to download gets stuck. we can also see below in console logs
|



The function calculated and updated startIndex but passed 0 to GetEventLog, breaking pagination. Now passes startIndex and eventLogBatchSize properly.
Fixes #1104
Manual Testing
Setup
Test Pagination API
Check event logs (page 1 - 5 records):
Check event logs (page 2 - next 5 records):
Generate More Events
Trigger power cycle to generate new event logs:
Trigger power action to generate likely AMT events (PowerCycle = 5)
Verified API pagination works:
Test Download (Fixed Endpoint)
Download all event logs via CSV:
You can manually download the csv file from UI or
Downloaded event logs via fixed endpoint:
Verify download contains all events:
Output:
Successfully downloaded 18 event logs from multiple boot cycles (timestamps show events from 08:57 and 09:36)
19 lines (18 events + 1 header)