An improperly formatted date causes an uninformative 500 error, and a useful message should instead be bubbled up to the user with a better error code.
This was brought to our attention by sentry, see: https://cmu-delphi.sentry.io/issues/4893721093/
One way to fix this: the offending date() constructor call that puked here (found in server/utils/dates.py:time_value_to_day()) can be wrapped to catch exceptions and then rethrow them as ValidationFailedexceptions. This is similar to what is done in other input processing methods in server/_params.py; those exceptions extend HTTPException which is handled and presented to the user gracefully by the web server.
We probbly also wanna do it with the similar Week() constructor call in time_value_to_week() as well, because i presume that will fail in an analogous way on unchecked/raw user input values.
An improperly formatted date causes an uninformative 500 error, and a useful message should instead be bubbled up to the user with a better error code.
This was brought to our attention by sentry, see: https://cmu-delphi.sentry.io/issues/4893721093/
One way to fix this: the offending
date()constructor call that puked here (found inserver/utils/dates.py:time_value_to_day()) can be wrapped to catch exceptions and then rethrow them asValidationFailedexceptions. This is similar to what is done in other input processing methods inserver/_params.py; those exceptions extendHTTPExceptionwhich is handled and presented to the user gracefully by the web server.We probbly also wanna do it with the similar
Week()constructor call intime_value_to_week()as well, because i presume that will fail in an analogous way on unchecked/raw user input values.