-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Fix gateway_error when no order is defined #4156
Fix gateway_error when no order is defined #4156
Conversation
We use the `controller` helper that RSpec provides, and so this class was never used.
If the current controller raises a gateway error, but does not have `@order` defined, this error handler will raise a NoMethodError when it tries to access `nil.errors`. We can resolve this by falling back to an empty Order instance if none is defined. This maintains the existing behaviour, and as the response only serializes the errors hash, there shouldn't be any surprises with null fields, etc. Signed-off-by: Alex Blackie <[email protected]>
These contexts were flipped accidentally.
Thanks, @alexblackie! Just to add some context, in which circumstances can this happen? I saw the specs but with a standard checkout flow it's very unlikely that we'll have an exception related to the gateway in a controller that is not related to the checkout where, I guess, having an order is mandatory. |
@kennyadsl Ah yeah, for context, this was raised in a custom reimbursements API controller, which interacts with payments (refunds) but does not have an Since the |
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.
Makes sense to me. Thanks, Alex!
Agree, thanks for sharing the context! |
If the current controller raises a gateway error, but does not have
@order
defined, this error handler will raise a NoMethodError when ittries to access
nil.errors
.We can resolve this by falling back to an empty Order instance if none
is defined. This maintains the existing behaviour, and as the response
only serializes the errors hash, there shouldn't be any surprises with
null fields, etc.
Checklist: