Hmmm.. The behaviour of the date range widget is definitely a little off, but it looks like it already was. Sometimes if you change the content of the date range to something that is not valid it 'silently' reverts back to what it was before, and sometimes it triggers the error and reverts to the default.

What we have here will prevent the 500 error, which is the desired outcome.

In an ideal world, we'd get feedback and a consistent result (either the default or reverting to what was before) in all these cases.

@wjwb-uk -- are you interested in digging deeper on this pull request, and making the whole thing work consistently with feedback, etc? That might be a bit of scope creep.

If not, would it be easy to have it revert to what was there before instead of the default?

@cielf Happy to dig a little deeper tonight. I hadn't noticed the silent reverts to old values, my gut is telling me it's something to do with the client side date picker.

To revert to the previous value after an invalid input, we’d need to store the last valid range somewhere, I'm thinking either in the session or passed along with the form as a hidden input. I feel like the hidden input is probably the cleaner solution here, since it keeps things stateless and works well with existing param based filtering. I’ll take a closer look and see if I can make the behavior more consistent with that approach if that sounds good to you?

I'm not the last word on technical approaches - but from a functional pov, I don't think it really matters whether we revert to a default or to what was there (will be the same in most cases), as long as we're consistent.

Merging main back in as I've been on vacation for a few weeks will revisit this week :)

Argh! @wjwb-uk I'm sorry -- it looks like we had a duplicate issue for this (see #4922), which is being actively worked on.

@cielf No sweat, these things happen. Will close merge request and pickup another issue :)