Skip to content

Added validation for maxCount#788

Open
parkdan26 wants to merge 2 commits into
OneBusAway:mainfrom
parkdan26:maxCount_validation
Open

Added validation for maxCount#788
parkdan26 wants to merge 2 commits into
OneBusAway:mainfrom
parkdan26:maxCount_validation

Conversation

@parkdan26

Copy link
Copy Markdown

Fixes #771

Problem

The maxCount query parameter is parsed, but errors are ignored.

Fix

Added validation to the parameter checking for a positive integer sending a error for negative and values greater then the limit. Also fixed test file to now accept the new requirements.

@aaronbrethorst aaronbrethorst left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Daniel — the direction is right: invalid maxCount values like "abc" should return 400 instead of silently falling back to the default. Two things need to be fixed before this can merge.


Critical Issues (1 found)

  1. Hard-capping maxCount at 50 is not in the OpenAPI spec and breaks valid requests. The spec (testdata/openapi.yml:1029) defines maxCount as a plain integer with no maximum — "The max number of results to return. Defaults to 20." A client requesting maxCount=100 should get 100 results, not a 400 error. The validation should reject non-positive values and non-integers, but should not impose an upper bound that the spec doesn't define. [search_stops_handler.go:55]

    Change:

    // Before (too restrictive)
    if err != nil || parsed <= 0 || parsed > 50 {
    
    // After (matches spec)
    if err != nil || parsed <= 0 {

Important Issues (1 found)

  1. Default value should be 20, not 50. The OpenAPI spec says "Defaults to 20" but the code defaults to 50 (limit := 50 on line 52). This is a pre-existing issue, but since you're already touching this code, please fix it to match the spec. [search_stops_handler.go:52]

Suggestions (2 found)

  1. The error message "need to be a positive integer" is grammatically incorrect — consider "must be a positive integer". [search_stops_handler.go:56]

  2. The "tooLarge" test case (maxCount=101) should be updated to expect http.StatusOK once the upper bound cap is removed, since 101 would become a valid value.

Strengths

  • Correctly identifies the silent fallback behavior as a problem
  • Test structure is good — table-driven with expected status codes
  • Adding the "abc" invalid string test case is a nice touch

Recommended Action

  1. Remove the parsed > 50 upper bound check
  2. Change default from 50 to 20
  3. Fix the error message grammar
  4. Update the "tooLarge" test case accordingly

@parkdan26

Copy link
Copy Markdown
Author

@aaronbrethorst Thank you for the feedback! I really appreciate it, I have committed the changes.

@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


Daniel Park seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
You have signed the CLA already but the status is still pending? Let us recheck it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Validate maxCount query parameter in search stops endpoint

3 participants