Improve Windows PowerShell curl instructions for health check , Fix i…

[jeyamoorthi]

Summary

Fixes incorrect HTTP status code when an agency is not found.

Problem

The API returned a 500 Internal Server Error when sql.ErrNoRows occurred while fetching an agency.

Solution

Added explicit handling for sql.ErrNoRows and return a 404 Not Found response.

Impact

• Aligns with REST API standards
• Improves client-side error handling
• Prevents misleading server error reporting

[CLAassistant]

All committers have signed the CLA.

[FLASH2332]

Hey, just curious — does it make sense to think about what this returns when the endpoint is behind auth? I've read that some APIs avoid returning a specific 404 in those cases to not reveal whether a resource actually exists. Wondering if that applies here!

[jeyamoorthi]

That’s a really good point ,, I did think about that while making the change. From what I understand, that pattern mostly matters when the existence of a resource itself is sensitive (like user data or private entities), where returning a 404 for everything helps prevent enumeration. In this case, since agencies are part of public GTFS data and not user-specific or confidential, I felt returning an accurate 404 is more appropriate and aligns better with REST semantics. It also helps clients distinguish between a missing resource and an actual server issue. That said, if there are plans to introduce user-scoped or private resources in the future, I agree this pattern would definitely be important to consider there.

…

On Sun, 22 Mar 2026 at 08:21, Jayadev D ***@***.***> wrote: *FLASH2332* left a comment (OneBusAway/maglev#770) <#770 (comment)> Hey, just curious — does it make sense to think about what this returns when the endpoint is behind auth? I've read that some APIs avoid returning a specific 404 in those cases to not reveal whether a resource actually exists. Wondering if that applies here! — Reply to this email directly, view it on GitHub <#770?email_source=notifications&email_token=BJHH2MF76TIL3ARIP322NPT4R5IJXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJQGUYTONZSGYY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4105177261>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJHH2MAH7OSOUL6WRYGUHO34R5IJXAVCNFSM6AAAAACW2MX7OCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMBVGE3TOMRWGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[tejasva-vardhan]

Great discussion here! @FLASH2332 brings up a very valid API security pattern regarding resource enumeration.

However, I completely agree with @jeyamoorthi's assessment in this specific context. For OneBusAway/Maglev, the API keys are primarily used for rate limiting, quotas, and usage tracking rather than strict data-level authorization. Since GTFS agency data is inherently public transit information, returning a standard 404 Not Found for an invalid agency_id is the correct RESTful approach. It's exactly what downstream clients need to gracefully handle missing feeds instead of crashing on a generic 500 Internal Server Error.

Good catch and solid fix on handling the sql.ErrNoRows gracefully! 🚀

[ARCoder181105]

@jeyamoorthi

The title of this PR seems inaccurate can you changes that to something that makes sense,

Like -> fix : http-status-response etc..

OR any other related title helps , it is help full for documenting the changes...

[aaronbrethorst]

superseded by #772