Fix incorrect next-page offset calculation

[c1-dev-bot]

Summary

• Fix offset pagination in pkg/bsql/query.go where pCtx.Offset was incorrectly treated as a page number instead of a row offset
• Changed pCtx.Offset * pageSize + pageSize to pCtx.Offset + pageSize
• Previously, pagination broke after 200 records (offset jumped from 200 to 10,100 with pageSize=100)

Test plan

• All existing tests pass (go test ./...)
• Verify pagination works correctly beyond 200 records with an offset-based SQL query

Fixes CXH-1261

[linear]

CXH-1261 Fix incorrect next-page offset calculation in baton-sql

[github-actions]

Claude finished @c1-dev-bot[bot]'s task in 53s —— View job

---

PR Review: Fix incorrect next-page offset calculation

• Gather context and read changed files
• Analyze the fix correctness
• Post review feedback

---

Verdict: Approve ✅

The fix is correct. Here's the trace confirming the bug and the fix:

In setupPagination (line 274), the pagination token is parsed directly as a row offset:

offset, err := strconv.ParseInt(pToken.Token, 10, 64)
ret.Offset = offset  // This IS a row offset, not a page number

Before (broken): pCtx.Offset * pageSize + pageSize at pkg/bsql/query.go:223

Page	Token	Offset	Next token
1	""	0	0*100+100 = 100 ✅
2	"100"	100	100*100+100 = 10100 ❌
3	"10100"	10100	10100*100+100 = 1010100 ❌

After (fixed): pCtx.Offset + pageSize

Page	Token	Offset	Next token
1	""	0	0+100 = 100 ✅
2	"100"	100	100+100 = 200 ✅
3	"200"	200	200+100 = 300 ✅

The old formula would have been correct if Offset were a zero-based page index (0, 1, 2...), but since setupPagination stores the raw row offset from the token, the multiplication was wrong.

One observation: There are no unit tests covering nextPageToken with the offset strategy. Adding a test would prevent regression. Here's a quick way to do that:

Add offset pagination test →

Overall this is a clean, minimal one-line fix for a real bug. LGTM.