-
-
Notifications
You must be signed in to change notification settings - Fork 725
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 flash error issues in checkout requests #5906
Fix flash error issues in checkout requests #5906
Conversation
I've tried writing controller tests for this, but the Capybara flash object doesn't seem to behave as expected. We need to check what it looks like after the action has finished, but it doesn't seem to be updated within the controller test. I've tested this in the browser and it's working as intended. |
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.
Nice one!
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.
Yes, man! 💐
Awesome @Matt-Yorkley ! I tested the two scenarios described in the issue and on your test notes:
Good to go, thanks for fixing this! 💪 PS: Outside of the scope of this PR, and to be addressed in a separate issue: - I noticed the case in which a memory-effect is visible after correcting the stock in an order, after reduction on checkout as described here still occurs; also, after triggering this flash message and navigating to the homepage the insufficient stock error appears there as well: |
Nice finding Filipe, would be good to get an issue for that last point. We will need a similar PR to this one but on another controller 👌 |
What? Why?
Closes #5895
Flash error messages created during checkout submission were being persisted in the flash session in unexpected ways, e.g. showing a checkout error message again after navigating away from the checkout page, or showing a message twice.
This was due to saving the errors in the flash session in XHR requests. The session is usually cleared after the subsequent action picks up the flash message, but here we needed to clear it after the current action, as the error is shown immediately via Angular on the checkout page (and shouldn't be persisted after that).
What should we test?
Release notes
Improved flash message display on checkout