Validation errors disappearing after Avo upgrade

[bradstewart]

So we're way behind the curve, but finally upgrading from Avo 2 -> 3. I've got most of the changes done, but one problem is driving me nuts:

ActiveRecord validation errors "disappear" and no longer displayed in the UI.

From the browser devtools + Rails logs, the ValidationError is thrown, a 422 response is given, and then the page reloads itself -- so the error never actually becomes visible (and the previous state of the record in question is reloaded in the view).

This happens across all of our resources.

Any ideas of something I might have missed in the upgrade process? Or config settings I might have screwed up (in Avo or Rails)? I'm... stuck.

Rails 7.2
Ruby 3.2.7
Avo 3.17
Avo-pro 3.17

[adrianthedev]

Hey Brad.
I can't look now but @Paul-Bob will have a look tomorrow.
I can tell you that that shouldn't happen.
Can you please post a recording of the page reloading. We want to see the page, the browser console and the rails console response.

Do you have any custom JS?
Any Avo monkeypatches?

My bet is that Turbo is failing somehow.

[Paul-Bob]

Here is the full 3.17.6 release

[bradstewart]

I'm not sure if I'm more or less confused now, but the issue appears to be our custom logger....

Removing this line from development.rb makes 3.17.6 work as expected.

  config.logger = Loggers::CustomDevLogger.new $stdout

Which means.... there must be some kind of bug in our logger which hadn't ever been hit until now? I guess some unhandled exception is getting tossed from that causing Rails to respond with the stock HTML error page, causing Turbo to go "welp this isn't what I expected let's reload the page" (although that doesn't make a ton of sense since we're seeing a 422 response and not a 500, but maybe).

It's not immediately obvious to me what the problem with it is, but I'll keep digging there as it certainly seems to be the culprit.

Very much appreciate the help in narrowing this down.

[Paul-Bob]

We do use Rails.logger.error, which was specifically introduced in version 3.17.6.

How does your custom logger handle the error method?

[bradstewart]

Finally closing the loop here -- I found the bug in our Logger. We had some... less than perfect code for concatting messages that was accidentally being called on error as well, and barfed when passed an Error instance (apparently we've never actually passed the full Error object to the logger...).

So this whole thing was our fault. Thank you again for your time here and the breadcrumbs.

[Paul-Bob]

Nice, glad you found it! Those sneaky bugs always pop up in the weirdest ways. Appreciate the update!