You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Enforce selectAll() exclusivity in the TypeScript SDK query builder #483
Enforce or explicitly define selectAll() exclusivity in the TypeScript SDK query builder.
selectAll() currently preserves previously selected columns, and select() preserves the selectAll state. As a result, these chains have inconsistent behavior:
select('page').selectAll() changes the projection to all readable columns.
selectAll().select('page') can send incompatible selection state.
selectAll().count() and similar aggregation chains reach the server and fail with HTTP 400.
Rationale
The SDK documentation states that selectAll() is mutually exclusive with explicit .select(...) calls and aggregations. The SDK should enforce this contract before a request is sent, or the documentation must describe the actual supported behavior consistently.
Affected areas
clients/ts/src/query-builder.ts
TypeScript SDK query-builder tests
docs/src/content/docs/sdk/queries.md
Acceptance criteria
Define the supported behavior when .selectAll() is combined with .select(...) or aggregation methods.
Enforce the behavior in the TypeScript SDK before sending an invalid request, or revise the SDK documentation to match the intentional behavior.
Add test coverage for both method orders.
Keep docs/src/content/docs/sdk/queries.md consistent with the SDK behavior.
Triage note: kept discrete, deliberately not folded into #199.
This was flagged as a fold candidate on the reasoning that selectAll() exclusivity is most naturally settled inside the query-builder restructure. Keeping it separate:
#199 is a large breaking restructure of the builder to match the new API routes, sitting under the #194 SDK epic with no timeline. This issue is a present-tense contract defect — selectAll().count() reaches the server and 400s today, and select('page').selectAll() silently changes the projection. Parking a live bug behind an unscheduled refactor means it ships in that state indefinitely.
Noted on #199 that the restructure must honour whatever contract this issue settles, so the two don't diverge if #199 lands first.
Related: #199 (query-builder restructure — must honour this contract), #194 (SDK epic).
Triage note from the pm-triage routine, 2026-08-25.
Activity
coderabbitai commentedon Aug 17, 2026
🔗 Related PRs
#313 - feat(docs): view-transition polish, branded search + 404, chrome pass [closed]
#448 - fix(sdk): keep a baseURL path prefix instead of discarding it [merged]
#455 - fix(test): enforce e2e poll budgets and stop reusing idle connections [merged]
#456 - feat(sdk)!: add options.headers, fetchOptions, and fetch [merged]
🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
EricAndrechek commentedon Aug 25, 2026
Triage note: kept discrete, deliberately not folded into #199.
This was flagged as a fold candidate on the reasoning that
selectAll()exclusivity is most naturally settled inside the query-builder restructure. Keeping it separate:#199 is a large breaking restructure of the builder to match the new API routes, sitting under the #194 SDK epic with no timeline. This issue is a present-tense contract defect —
selectAll().count()reaches the server and 400s today, andselect('page').selectAll()silently changes the projection. Parking a live bug behind an unscheduled refactor means it ships in that state indefinitely.Noted on #199 that the restructure must honour whatever contract this issue settles, so the two don't diverge if #199 lands first.
Related: #199 (query-builder restructure — must honour this contract), #194 (SDK epic).
Triage note from the pm-triage routine, 2026-08-25.