https://sonarly.com/issue/30901?type=bug
The REST API pagination parameter is `starting_after` (not `cursor`), but the API silently ignores unrecognized query parameters, causing users who guess the wrong parameter name to get an infinite loop of duplicate records.
Fix: Added detection of commonly-misused pagination parameter names in both cursor parsers. When a user passes `cursor`, `after`, `lastCursor`, `last_cursor`, `startingAfter`, or `page_token` instead of `starting_after` (or `before`, `endingBefore`, `ending` instead of `ending_before`), the API now returns a 400 Bad Request with a clear error message like: "Unknown pagination parameter 'cursor'. Use 'starting_after' instead".
Changes:
1. `parse-starting-after-rest-request.util.ts` — Added a check for 6 common wrong parameter names. When `starting_after` is absent but one of these is present, throws `RestInputRequestParserException` with the new `INVALID_CURSOR_QUERY_PARAM` code. When `starting_after` IS present, wrong names are ignored (no false positives).
2. `parse-ending-before-rest-request.util.ts` — Same pattern for 3 common wrong names for the ending_before parameter.
3. `rest-input-request-parser.exception.ts` — Added `INVALID_CURSOR_QUERY_PARAM` enum value and its user-friendly message in the switch statement. The existing `assertUnreachable` default ensures compile-time exhaustiveness.
4. Both test files updated with cases for wrong parameter detection and a case confirming no false positive when the correct parameter is also present.
The existing exception handler already maps `RestInputRequestParserException` → `BadRequestException` (HTTP 400), so no handler changes were needed.
Sonarly Claude Code
4904da0459