fix :- return 404 when no stops match prefix query in search-stop

[Aaravanand00]

This PR completes the remaining spec parity requirements for the /api/where/search/stop.json endpoint mentioned in #1162.

Changes included :-

• internal/restapi/search_stops_handler.go: Updated the handler to properly return an HTTP 404 Not Found response if the database query returns 0 stops (pre-filter empty state). Previously, it fell through to return 200 OK with an empty list.
• internal/restapi/search_stops_handler_test.go: Updated the TestSearchStopsHandlerNoResults test to assert http.StatusNotFound instead of http.StatusOK, aligning the test with the actual required spec behavior.

Note: All other requirements from #1162 (such as route-type exclusions, includeReferences, exact-boundary limitExceeded, parent station resolution, and sorting) are already covered by existing tests merged in previous PRs (like #1164 and #1284).

Fixes #1162

Summary by CodeRabbit

• Bug Fixes
  • Stop searches that return no matches now respond with a 404 Not Found error instead of a successful response containing an empty list.
  • The error response includes a 404 status code for clearer handling by clients.
  • Searches with matching stops continue to return successful responses and results as expected.

[CLAassistant]

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.

---

Aaravanand 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.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 9e1d3902-c5ca-4c04-a56c-97ad9aca5841

📥 Commits

Reviewing files that changed from the base of the PR and between 6b2bd78 and 7242ec1.

📒 Files selected for processing (2)

• internal/restapi/search_stops_handler.go
• internal/restapi/search_stops_handler_test.go

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The stop search handler now returns HTTP 404 when no stops match. Tests verify the HTTP status and error response code for empty and non-matching queries.

Changes

Stop search not-found behavior

Layer / File(s)	Summary
Empty search result response internal/restapi/search_stops_handler.go, internal/restapi/search_stops_handler_test.go	The handler returns sendNotFound before pagination and related-data processing when no stops match. Tests expect HTTP 404 and an error response code of 404 for non-matching inputs, while matching inputs still expect HTTP 200.

Priority: ⬇️ Low

Estimated code review effort: 1 (Trivial) | ~5 minutes

Merge Risk: ⚪ Minimal · up to 7242e

Stop searches with no database matches now return the standard 404 response, with tests covering empty and non-matching results. No current merge-blocking risk remains.

Suggested reviewers: arcoder181105, burma-shave

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the primary change: returning HTTP 404 when no stops match the search query. The punctuation and grammar are awkward but do not obscure the change.
Linked Issues check	✅ Passed	The handler now returns 404 for pre-filter searches with no matching stops, and the related tests verify both the HTTP status and error response code. This satisfies the no-results requirement in issu…
Out of Scope Changes check	✅ Passed	All changes are limited to the stop-search handler and its tests. They directly support the 404 no-results behavior required by issue #1162.

• Fix all pre-merge checks with AI

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[omlahore]

I think the pre-filter rule only lands on one of the two paths that can return zero matches. sanitizeFTS5Query strips the input before the query is built, so input=" " or input='*()"' or input="!!!" all bail out at the len(terms) == 0 return further up with a 200 and an empty list, and never reach the new check.

On the RABA fixture that gives "NonExistentStopName12345" a 404 but "!!!" a 200, and both of those matched nothing before any filtering. I am not sure whether #1162 means unparseable input to be its own case, but if it does I guess it is worth a line in the test so the split is deliberate rather than just where the early return happens to sit.