Reject --sort-by where the API has no sortBy parameter - #10
Merged
arcaputo3 merged 1 commit intoAug 5, 2026
Merged
Conversation
Only /events accepts sortBy (enum: id, date — confirmed against the live API). Everywhere else the CLI's allow-list dropped the flag before building the request, and those endpoints return rows in insertion order, so a caller who passed --sort-by date got the oldest documents on page one with no indication anything had gone wrong. Add sortFields to the resource table and validate against it. An unknown field on events, or any --sort-by on a resource that cannot sort, now exits 2 and points at the events-first recipe. --direction is left alone: every list endpoint accepts it, it just reverses insertion order rather than date order. Closes #4 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #4. Stacked on #9 (review the second commit only).
What the API actually does
Verified against the live API rather than inferred:
/events?sortBy=bogus400 — sortBy must be one of the following values: id, date/documents/transcripts?sortBy=date400 — property sortBy should not exist/documents/transcripts?direction=desc200, and it does reverse the orderSo
/eventsis the only list endpoint with asortByparameter, and its enum isid, date. The issue reports the flag as "silently dropped" — it is:toParamsgates every parameter on a per-resource allow-list andsortByis only in the events set, so the flag never reaches the wire and nothing complains.That silence is the whole bug. Document endpoints return rows in insertion order, so
transcripts list --tickers X --sort-by date --direction descyields the oldest transcripts on page one, looking exactly like a correct answer.Change
resource.sortFieldsrecords the accepted enum per resource; onlyeventshas one.validateSortByrejects an unknown field on events, and any--sort-byon a resource that cannot sort, before any request goes out.usageErrortype, mapped inRun) so scripts can tell a bad command line from a failed request.pages/chaptersreject--sort-bytoo — they inherit the shared list flags but sort by nothing.--helpshare one recipe paragraph, so they cannot drift apart.--directionis deliberately untouched: it is accepted everywhere and works, it just reverses insertion order rather than date order. The message says so, since that distinction is what makes the flag misleading.On
companies list, where--event-idsdoes not exist, the recipe collapses to "onlyevents listsupports--sort-by".Tests
Four cases: rejection on an unsortable resource (asserting no HTTP request is made), unknown field on events,
sortBy/directionstill forwarded for a valid events sort, and rejection onpages.🤖 Generated with Claude Code