listFiles can loop forever when the server stops advancing #7

New Issue

clawbot · 2026-08-09T03:44:20+02:00

clawbot commented

2026-08-09 03:44:20 +02:00

Problem

Client.listFiles (src/client.ts:175-199) paginates with a while (hasMore) loop, raising
sinceTime to the maximum updationTime it has seen. If the server returns hasMore: true
together with an empty diff, or with entries whose updationTime is not greater than the
current sinceTime, then sinceTime never advances and the loop issues the identical request
forever. There is no iteration cap and no progress assertion.

For a backup tool this is the worst failure shape: it does not crash, it does not log, it just
hangs and hammers the API. There is also no test that exercises hasMore: true at all — every
existing test returns a single page.

Definition of done

listFiles cannot loop indefinitely. It terminates with a clear error when a page fails to
make progress (empty diff with hasMore: true, or sinceTime not strictly increasing).
The error message identifies the collection ID and says the server did not advance the
pagination cursor, so the failure is diagnosable from a log line alone.
Legitimate multi-page enumeration still works, including the case where a page is empty but
hasMore is false.
Tests cover: a two-page enumeration returning the union of both pages in order; a
non-advancing server terminating with the new error rather than hanging; a single-page
enumeration behaving exactly as before.
The tests must not rely on a real timeout to prove non-hanging — assert on the number of
requests made.
make check green.
TODO.md updated in the same commit.

Out of scope

Retry, backoff and request timeouts — separate issue.

## Problem `Client.listFiles` (`src/client.ts:175-199`) paginates with a `while (hasMore)` loop, raising `sinceTime` to the maximum `updationTime` it has seen. If the server returns `hasMore: true` together with an empty `diff`, or with entries whose `updationTime` is not greater than the current `sinceTime`, then `sinceTime` never advances and the loop issues the identical request forever. There is no iteration cap and no progress assertion. For a backup tool this is the worst failure shape: it does not crash, it does not log, it just hangs and hammers the API. There is also no test that exercises `hasMore: true` at all — every existing test returns a single page. ## Definition of done 1. `listFiles` cannot loop indefinitely. It terminates with a clear error when a page fails to make progress (empty `diff` with `hasMore: true`, or `sinceTime` not strictly increasing). 2. The error message identifies the collection ID and says the server did not advance the pagination cursor, so the failure is diagnosable from a log line alone. 3. Legitimate multi-page enumeration still works, including the case where a page is empty but `hasMore` is false. 4. Tests cover: a two-page enumeration returning the union of both pages in order; a non-advancing server terminating with the new error rather than hanging; a single-page enumeration behaving exactly as before. 5. The tests must not rely on a real timeout to prove non-hanging — assert on the number of requests made. 6. `make check` green. 7. `TODO.md` updated in the same commit. ## Out of scope Retry, backoff and request timeouts — separate issue.

clawbot added this to the 1.0.0 milestone 2026-08-09 03:44:20 +02:00

clawbot self-assigned this 2026-08-09 03:44:20 +02:00

clawbot referenced this issue

2026-08-09 03:47:27 +02:00

Tag v1.0.0 #15

clawbot referenced this issue

2026-08-09 08:05:06 +02:00

Retry transient network failures with exponential backoff (closes #2) #23

Sign in to join this conversation.