currently errors that manage to hit the server come back as "notification" type errors, which is scary for users, especially if they're backend errors with cryptic messages like error: repo: invalid Profile.Email blah blah. I think we can compensate for this by catching as many errors as possible on the frontend before sending to the server.
There will always be the potential for drift between client & server validation, so the long term fix for this issue is to have better plumbing on the frontend to place API error responses in the right place, but I think we should tackle that as part of a more general API integration improvement.
So I think we can close this issue once we have a set of tests the confirm our frontend code catches all the validation errors currently specified on the backend. Bonus points if we can copy-paste the backend jsonschema to keep frontend tests up-to-date.
currently errors that manage to hit the server come back as "notification" type errors, which is scary for users, especially if they're backend errors with cryptic messages like
error: repo: invalid Profile.Email blah blah
. I think we can compensate for this by catching as many errors as possible on the frontend before sending to the server.There will always be the potential for drift between client & server validation, so the long term fix for this issue is to have better plumbing on the frontend to place API error responses in the right place, but I think we should tackle that as part of a more general API integration improvement.
So I think we can close this issue once we have a set of tests the confirm our frontend code catches all the validation errors currently specified on the backend. Bonus points if we can copy-paste the backend jsonschema to keep frontend tests up-to-date.