Repository navigation
[BUG] HTTP 404 error (Not Found) reported for unrecognized date input to API #159
Description
Describe the bug
When calling API endpoint /api/channels/CHANNEL_ID/messages with a malformed startDate, a 404 is returned. It should return a 400 (or other appropriate) status with details on why the request failed.
To Reproduce
- Start server
- Create a channel
- Call the endpoint with the given channel ID:
/api/channels/CHANNEL_ID/messages?limit=5 - Notice a 200 response
- Call the endpoint with the given channel ID and valid startDate:
/api/channels/CHANNEL_ID/messages?startDate=1985-10-26T09%3A00%3A00.000-0700&limit=5 - Notice a 200 response
- Call the endpoint with given channel ID and invalid startDate:
/api/channels/CHANNEL_ID/messages?startDate=1985&limit=5 - Notice a 404 response
Environment (please complete the following information):
- Windows 10
- OpenJDK 11.0.27
- OIE 4.5.2
Additional context
Original ticket - nextgenhealthcare/connect#6144
Summary table in #121
Activity
rogin commentedon Aug 12, 2025
Moving my comment from #121.
Sample server response containing invalid date format:
{ "servlet": "org.glassfish.jersey.servlet.ServletContainer-6337a15e", "message": "Not Found", "url": "/api/channels/f8790fdf-8aab-4961-9855-0fed9a1a4469/messages", "status": "404" }The startDate format is clearly provided in the swagger API, so the user knowingly provided an invalid string.
I agree that 404 is not the right response when the date format is incorrect and 400 is more appropriate.
AI says Jersey's default behavior is to throw a 404 when a parse exception occurs, which matches the server output above. Several options may be available for this, but it's worth discussing a generalized solution to satisfy multiple endpoints.
rogin commentedon Aug 12, 2025
I expected being able to write a ParamConverter for Calendar conversions, then catch the exception type it throws in an ExceptionMapper. The existing ParamConverter is in CalendarParamConverterProvider, so I created
CalendarParseExceptionMapper. If I useextends ExceptionMapper<WebApplicationException>(and making sure the converter throws that exception type), it works as expected for Calendar conversion errors. However, it also catches 401 Unauthorized exceptions as well (of class MirthApiException). It was odd and unexpected, so I switched toextends ExceptionMapper<CalendarParseException>with a custom exception class being thrown in the converter, and it never activated.This had me looking further into the app's design. It appears that MirthResourceInvocationHandlerProvider#convertThrowable goes digging to ensure an exception chain is ordered InvocationTargetException>MirthApiException>WebApplicationException with all other exceptions being wrapped with InvocationTargetException. I welcome fresh eyes on options at this point as I feel like I'm missing an obvious solution.
You can also see a bit more of this expected exception ordering in ServletTestBase#assertForbiddenException
As an aside, I had wondered why some calls to JSON endpoints would return XML. Well a certain constructor to MirthApiException makes that happen. It's ugly, and it should go.
tonygermano commentedon Aug 12, 2025
Thanks for the research on this
Return 400 instead of 404 for a malformed date query parameter (fixes O…
Return 400 instead of 404 for a malformed date query parameter (fixes O…