Summary
basecamp campfire messages --limit N always returns 15 messages regardless of N.
Only one HTTP request is ever made, despite the API returning a Link: rel="next" header
and X-Total-Count: 1606.
Related to #284 — both stem from the same broken pagination path. Tested while running a
self-written skill to summarize the last N messages from a campfire.
Note: SDK v0.4.0 (basecamp/basecamp-sdk@92026d6) added followPagination support to ListLines, but it isn't working end-to-end — only one HTTP request is ever made.
This issue was generated with Claude's assistance.
Steps to Reproduce
basecamp campfire messages --in <project_id> --limit 15 --quiet --json | jq 'length' # => 15
basecamp campfire messages --in <project_id> --limit 75 --quiet --json | jq 'length' # => 15
basecamp campfire messages --in <project_id> --limit 200 --quiet --json | jq 'length' # => 15
Confirmed with -vv — only one request fires regardless of --limit:
-> GET .../chats/<id>/lines.json
<- 200
The API paginates correctly:
TOKEN=$(basecamp auth token --account <account_id> --quiet)
curl -sI ".../chats/<id>/lines.json" -H "Authorization: Bearer $TOKEN" | grep -i 'link\|x-total'
# link: <.../lines.json?page=2>; rel="next"
# x-total-count: 1606
Root Cause
Three bugs in the call chain:
1. --limit is never passed to the SDK
|
result, err := app.Account().Campfires().ListLines(cmd.Context(), chatIDInt, nil) |
nil opts causes the SDK to use DefaultCampfireLineLimit = 100:
https://github.com/basecamp/basecamp-sdk/blob/92026d65a1561dcc220b9bd4e9e8460e08a92045/go/pkg/basecamp/campfires.go#L338
The user's --limit value is only applied afterwards as an in-memory slice — it never influences how many pages the SDK fetches.
2. followPagination silently returns after page 1
https://github.com/basecamp/basecamp-sdk/blob/92026d65a1561dcc220b9bd4e9e8460e08a92045/go/pkg/basecamp/campfires.go#L353
Despite a valid Link header on the response, followPagination never calls doRequestURL for subsequent pages:
https://github.com/basecamp/basecamp-sdk/blob/3b956d4d4df2443067af31c5ef5624cd728eeffa/go/pkg/basecamp/client.go#L484
The exact early-return condition requires instrumentation to pinpoint — all static guards we checked (nil response, limit check, Link header parsing, same-origin validation) should pass.
3. In-memory slice takes the wrong end
|
if limit > 0 && len(lines) > limit { |
The API returns messages newest-first. Taking the tail returns the oldest messages — consistent with #284's report of Aug 2025 messages from an active campfire.
Expected Behavior
--limit N should paginate via Link: rel="next" headers until N messages are collected
(or no more pages remain), and return the N most recent messages.
Environment
Summary
basecamp campfire messages --limit Nalways returns 15 messages regardless of N.Only one HTTP request is ever made, despite the API returning a
Link: rel="next"headerand
X-Total-Count: 1606.Related to #284 — both stem from the same broken pagination path. Tested while running a
self-written skill to summarize the last N messages from a campfire.
Note: SDK v0.4.0 (basecamp/basecamp-sdk@92026d6) added
followPaginationsupport toListLines, but it isn't working end-to-end — only one HTTP request is ever made.This issue was generated with Claude's assistance.
Steps to Reproduce
Confirmed with
-vv— only one request fires regardless of--limit:The API paginates correctly:
Root Cause
Three bugs in the call chain:
1.
--limitis never passed to the SDKbasecamp-cli/internal/commands/chat.go
Line 256 in 73863c9
nilopts causes the SDK to useDefaultCampfireLineLimit = 100:https://github.com/basecamp/basecamp-sdk/blob/92026d65a1561dcc220b9bd4e9e8460e08a92045/go/pkg/basecamp/campfires.go#L338
The user's
--limitvalue is only applied afterwards as an in-memory slice — it never influences how many pages the SDK fetches.2.
followPaginationsilently returns after page 1https://github.com/basecamp/basecamp-sdk/blob/92026d65a1561dcc220b9bd4e9e8460e08a92045/go/pkg/basecamp/campfires.go#L353
Despite a valid
Linkheader on the response,followPaginationnever callsdoRequestURLfor subsequent pages:https://github.com/basecamp/basecamp-sdk/blob/3b956d4d4df2443067af31c5ef5624cd728eeffa/go/pkg/basecamp/client.go#L484
The exact early-return condition requires instrumentation to pinpoint — all static guards we checked (nil response, limit check, Link header parsing, same-origin validation) should pass.
3. In-memory slice takes the wrong end
basecamp-cli/internal/commands/chat.go
Line 263 in 73863c9
The API returns messages newest-first. Taking the tail returns the oldest messages — consistent with #284's report of Aug 2025 messages from an active campfire.
Expected Behavior
--limit Nshould paginate viaLink: rel="next"headers until N messages are collected(or no more pages remain), and return the N most recent messages.
Environment