Both audits flagged buildPage as a non-blocking but worth-cleaning nit: it re-derived next_cursor from len(events) and the last event's ID rather than using the HasMore + NextCursor flags that event.Repository.ListByToken already computes via the LIMIT+1 peek trick. Both calculations agreed today, but the duplication would mask a divergence if the repo's pagination logic ever evolved (e.g. switched to opaque token cursors). Inline buildPage into gatherManageData and use list.HasMore + list.NextCursor as the authoritative signals. Drops the buildPage helper. Behavior identical; tests still pass. |
||
|---|---|---|
| .. | ||
| generators | ||
| contract.go | ||
| dto.go | ||
| entity.go | ||
| handler.go | ||
| handler_test.go | ||
| repository.go | ||
| repository_test.go | ||
| service.go | ||
| service_test.go | ||
| types.go | ||