Conversation
ListWorkflows now fetches all pages automatically (250/page) instead of silently truncating at the first 100 results. With 300+ workflows on prod, the old behavior hid workflows from all list operations. Manual pagination still works via --cursor for single-page fetches.
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical issue where the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces automatic pagination for the wf list command. The review focuses on a breaking change in the behavior of the --limit flag, a magic number that could be a constant, and a suggestion for clarifying a command-line flag's help text.
| func (c *Client) ListWorkflows(opts ListWorkflowsOptions) (*ListResult[Workflow], error) { | ||
| // Manual pagination: caller provided a cursor, return single page | ||
| if opts.Cursor != "" { | ||
| return c.listWorkflowsPage(opts) | ||
| } | ||
|
|
||
| pageSize := opts.Limit | ||
| if pageSize <= 0 { | ||
| pageSize = 250 | ||
| } | ||
|
|
||
| var all []Workflow | ||
| pageOpts := opts | ||
| pageOpts.Limit = pageSize | ||
|
|
||
| for { | ||
| page, err := c.listWorkflowsPage(pageOpts) | ||
| if err != nil { | ||
| return nil, err | ||
| } | ||
| all = append(all, page.Data...) | ||
|
|
||
| if page.NextCursor == "" || len(page.Data) == 0 { | ||
| break | ||
| } | ||
| pageOpts.Cursor = page.NextCursor | ||
| } | ||
|
|
||
| return &ListResult[Workflow]{Data: all}, nil | ||
| } |
There was a problem hiding this comment.
This new implementation of ListWorkflows changes the behavior of the --limit flag in a breaking way. Previously, it limited the total number of results. Now, it controls the page size for auto-pagination, and there is no longer a way to limit the total number of returned workflows. This can be surprising to users and may cause performance issues if they unintentionally fetch a very large number of workflows.
Consider re-introducing a way to limit the total number of results, perhaps by making --limit a total limit again and adding a new --page-size flag for when pagination is desired.
There was a problem hiding this comment.
This is the intentional behavior change — the whole point of this PR. The old --limit 100 default silently hid 210 of 310 workflows on prod. Nobody was using --limit to deliberately cap results; it was just a page size that happened to truncate output.
This is an internal CLI (n8nctl), so there's no external compatibility concern. Adding a separate --page-size flag would be YAGNI.
internal/api/client.go
Outdated
|
|
||
| pageSize := opts.Limit | ||
| if pageSize <= 0 { | ||
| pageSize = 250 |
There was a problem hiding this comment.
The default page size 250 is used here as a magic number. It's better to define this as a constant at the package level, for example const defaultListPageSize = 250. This improves code clarity and maintainability.
There was a problem hiding this comment.
Fixed — extracted to defaultListPageSize constant.
internal/cmd/workflow/workflow.go
Outdated
| cmd.Flags().StringSliceVar(&tags, "tag", nil, "Filter by tag (can be repeated)") | ||
| cmd.Flags().IntVar(&limit, "limit", 100, "Maximum number of workflows to return") | ||
| cmd.Flags().StringVar(&cursor, "cursor", "", "Pagination cursor for next page") | ||
| cmd.Flags().IntVar(&limit, "limit", 0, "Maximum number of workflows per page (0 = auto-paginate all)") |
There was a problem hiding this comment.
The help text (0 = auto-paginate all) is a bit misleading. With the new implementation, auto-pagination of all results happens for any value of --limit, with the value determining the page size. The special case for 0 is that it uses a default page size (250). A clearer description would improve user understanding.
| cmd.Flags().IntVar(&limit, "limit", 0, "Maximum number of workflows per page (0 = auto-paginate all)") | |
| cmd.Flags().IntVar(&limit, "limit", 0, "Maximum number of workflows per page; all pages are fetched (0 = default size)") |
There was a problem hiding this comment.
Fixed — updated to Page size per API request (0 = default).
Address Gemini review feedback: - Extract magic number 250 to defaultListPageSize constant - Clarify --limit flag description (all values auto-paginate)
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
1 participant
Summary
wf listnow auto-paginates through all pages (250/page) instead of silently truncating at 100--cursorstill works for single-page fetches--limitdefault changed from 100 to 0 (= fetch all)What changed
ListWorkflowsin the API client now loops through pages automaticallylistWorkflowsPage(unexported)Test plan
n8nctl wf list --jsonreturns 310 workflows (was 100)n8nctl wf list --activereturns 81 (was truncated to whatever fit in page 1)--cursorflag still works for manual single-page fetchgo build ./...passes