paginate() in pagination.ts at line 109 enters an infinite loop when a filtered list endpoint returns { items: [], nextToken: 'cursor' }. The CLI hangs indefinitely and must be force-killed.
To reproduce this, run testsprite test list --project with a filter that matches zero results. The API responds with an empty items array but still includes a nextToken. The CLI never exits because it keeps requesting the same empty page over and over.
The root cause is that the pagination logic checks nextToken != null to decide whether to keep looping, but it never checks whether items is actually empty. There is an early-exit guard (remaining <= 0) but that only kicks in when --max-items is explicitly set. Without it, the loop has no way to stop for this edge case. This response shape is documented in http.ts, so this is a client-side handling issue, not a server bug.
The expected behavior is that paginate() should break out of the loop when the API returns an empty items array, regardless of what nextToken says. A simple fix would be adding something like:
if (items.length === 0) break;
Another option is to track consecutive empty responses and break after 2 or 3 to handle transient empty pages more gracefully.
This is a critical issue since any user calling a list command without --max-items on a filter returning no results will experience a complete hang with no workaround other than killing the process.
I'd like to work on this and submit a PR if that's okay. Let me know if there's a preferred branching convention or anything else I should know before starting.
paginate() in pagination.ts at line 109 enters an infinite loop when a filtered list endpoint returns { items: [], nextToken: 'cursor' }. The CLI hangs indefinitely and must be force-killed.
To reproduce this, run testsprite test list --project with a filter that matches zero results. The API responds with an empty items array but still includes a nextToken. The CLI never exits because it keeps requesting the same empty page over and over.
The root cause is that the pagination logic checks nextToken != null to decide whether to keep looping, but it never checks whether items is actually empty. There is an early-exit guard (remaining <= 0) but that only kicks in when --max-items is explicitly set. Without it, the loop has no way to stop for this edge case. This response shape is documented in http.ts, so this is a client-side handling issue, not a server bug.
The expected behavior is that paginate() should break out of the loop when the API returns an empty items array, regardless of what nextToken says. A simple fix would be adding something like:
Another option is to track consecutive empty responses and break after 2 or 3 to handle transient empty pages more gracefully.
This is a critical issue since any user calling a list command without --max-items on a filter returning no results will experience a complete hang with no workaround other than killing the process.
I'd like to work on this and submit a PR if that's okay. Let me know if there's a preferred branching convention or anything else I should know before starting.