-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Propagate Django error messages from Transaction Service #1226
Conversation
const httpErrorFactory = { | ||
from: jest.fn(), | ||
} as jest.MockedObjectDeep<HttpErrorFactory>; | ||
const mockHttpErrorFactory = jest.mocked(httpErrorFactory); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I migrated to using the real HttpErrorFactory as we were mocking and testing the mocked functionality which didn't make much sense. Would welcome your thoughts regarding this.
Pull Request Test Coverage Report for Build 8100115384Details
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've only left small nits, but it LGTM 👏🏻
Glad to see a lot of tests were added 💪🏻
// Map Django error as "standard" error message if present | ||
const djangoError = get(error.data, 'nonFieldErrors[0]'); | ||
if (djangoError) { | ||
return new NetworkResponseError(error.url, error.response, { | ||
message: djangoError, | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: should we abstract from the technology used by the data source? I mean, what about changing the django
references here and in the tests for another generic concept like transactionService
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And also other nits:
nonFieldErrors[0]
might be extracted to a class constant, wdyt?- This assumes we are only interested in the first error in the payload, aren't we? I'm ok with this as long as this is ok for the clients.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I generalised all references to "Django" (preferring "Transaction Service") in 931505d, as well as moving the path to a constant. I also added a comment explaining the reasoning for returning the first error element - a string is preferred.
Summary
This adds an error mapper to the
TransactionApi
service that maps Django error messages (nonFieldErrors[0]
) if present to be the "standard" errormessage
.Changes
TransactionApi['mapError']
and use it within all callsTransactionApi