It's not usually valid, but can still be entered. I wasn't able to fix the positioning of the :after psuedo element without having a child text node. Maybe it's possible to add an empty child text node, but I didn't think it worth getting down to that level..
Using browser validation. I didn't use model validation because the on_hand pseudo-attribute doesn't support it.
But.. it turned out to not be so simple. Browser validation can't work if the field is hidden, and breaks the javascript. So now I made the javascript smarter, and the end result is more helpful I think.
And thus give the user a useful message to try again.
Hmm, if this is a good idea, we should do it everywhere we upload an image. Can we build that in somehow, or at least make a shared helper that accepts a block and catches the error?
I replicated this in dev a couple of times, I think with a text file labelled as an image file. Unfortunately, I can no longer replicate in dev or with a spec.
The hiredis client was praised as being faster parsing bulk responses
but it seems to have multiple issues now:
- The redis release 5.0 moved hiredis support to another gem.
- I tried the hiredis-client gem and it raised errors.
- There are claims of worse performance of hiredis [1].
- Maintenance responsiveness has been questioned [2].
Using the default redis driver seems to work fine though.
[1]: https://discuss.rubyonrails.org/t/hiredis-does-not-support-ssl-action-cable/75945
[2]: https://github.com/redis/hiredis/issues/655
The default action when a user submit the form too quickly is to
redirect to :back with flash error message. As we are using CableReady
it's not working for us, so I render_alert_timestamp_error_message
to show the error message to the user.
It represent a collection of enterprise fee adjustments. Currently
it only allows you to calculate the tax amount relating to enterprise
fees when tax is not included in price
A StimulusReflex form handler was being ignored, resulting in an error.
Note that this method can support angular forms, the submit buttons just need to be updated to type='submit' (why they are not already boggles me).
Why mask the actual exception with a made-up one? The name did convey a bit more context, but Bugsnag tracks the context anyway. It would be more helpful to record the details of the error.
Just in case, I checked if there were any recorded instances of StripeDeauthorizeFailure. I couldn't find any in Bugsnag (last 3 months) for AU, Germany, Katuma, NZ, Norway, UK, USA. Also no mention in GitHub issues.
