* Alter config so an error will be raised if you forget to mock out a
celery call in one of your tests
* Remove an unneeded exception type that was masking errors
We now have a new column in the database, but it isn't being
populated. The first step is to make sure we update this column,
while still keeping the old enum based column up to date as well.
A couple of changes have had to happen to support this - one irritating
thing is that if we're ever querying columns individually, including
`Notification.status`, then we'll need to give that column a label,
since under the hood it translates to `Notification._status_enum`.
Accessing status through the ORM (i.e., my_noti.status = 'sending' or
similar) will work fine.
- Use these validation methods in post_sms_notification and the version 1 of post_notification.
- Create a v2 error handlers.
- InvalidRequest has a to_dict method for private and v1 error responses and a to_dict_v2 method to create the v2 of the error responses.
- Each validation method has extensive unit tests, so the unit test for the endpoint do not need to check every error case, but check that the error handle formats the message correctly.
- The format of the error messages is still a work on progress.
- This version of the api could be deployed without causing a problem to the application.
- The new endpoing is still a work in progress and is not being used yet.
ensure that if unexpected Exceptions are thrown, we handle them correctly
(log and then return JSON)
also remove some branches that will never trip, and combine a couple of
identical functions
hopefully cleans up code flow and readability [a tiny bit].
raise an AuthException in auth.py, and catch it in errors.py to
save on returning error_repsonse values throughout the function
or param errors to raise invalid data exception. That will cause
those responses to be handled in by errors.py, which will log
the errors.
Set most of schemas to strict mode so that marshmallow will raise
exception rather than checking for errors in return tuple from load.
Added handler to errors.py for marshmallow validation errors.
they do not raise exceptions.
Introduced a simple exception that contains error messages and status
code that can be used rather than return json + status code from rest
methods directly.
The handler in errors for this exception can then log the error before
returning json.
There is a uniqueness constraint on service `name` and `email_from`.
When you try to insert a row which has _both_ constraints, there is no
guarantee which one the operation will fail on.
This means that, when handling the exception, service `name` is not
reliably available, because sometimes the operation fails on the
`email_from` constraint instead.
This caused the tests to fail non-deterministically because they were
looking for the service `name` in the error message. As a fix, this
commit does two things:
1. Return either the service `name` or `email_from` in the error
message, depending which is available.
2. Modify the test to pass on _either_ of the two possible error
messages.
This is not ideal, but I can’t think of a way to maintain the original
behaviour, and have reliably passing tests.
Refactored service/rest.py so that all methods are returning a properly formatted error message so that the error message can deal with the response.
Refactoed errors.py to properly format the error message.
- Created new endpoint user/<user_id>/sms-code to send the sms verification code to the user.
- Create new endpoirtn user/<user_id>/email-code to send the email verifcation code to the user.
- Marked the old methods, schema, tests with a TODO to be deleted when the admin app is no longer sending messages to /user/<user_id>/code
- Added error handlers for DataError and NoResultFound. Data error catches invalid input errors.
- Added error handler for SqlAlchemyError which catches any other database errors.
- Removed the need for the try catches around the db calls in the user endpoints with the addition of the db error handlers.
- We may want to wrap db excpetions in the dao, if we want the No results found message to be more specific and say no result found for user.
