[BUG] NoMethodError for Plain String inside inertia error props in redirects

[PedroAugustoRamalhoDuarte]

Bug Description

After upgrading to inertia-rails 3.4.0, an error occurs in our application that wasn't present in version 3.3.0. The error seems related to how inertia expects errors props.

Error Details

When attempting to redirect with a plain string as the errors value, the following error is raised:

  1) SessionsController POST /sign_in with invalid credentials returns unauthorized status
     Failure/Error: redirect_to sign_in_path, inertia: { errors: "Credenciais Inválidas" }
     
     NoMethodError:
       undefined method `to_hash' for an instance of String
     # ./app/controllers/sessions_controller.rb:22:in `create'
     # ./spec/requests/sessions_controller_spec.rb:26:in `block (4 levels) in <top (required)>'

Steps to Reproduce

1. Upgrade inertia-rails from version 3.3.0 to 3.4.0.
2. Add a redirect_to call in your controller that passes a plain string in the inertia data, as shown below:

   redirect_to sign_in_path, inertia: { errors: "Credenciais Inválidas" }

3. Run the code or corresponding tests.

Relevant Code Snippet

Here's the controller action causing the error:

def create
  user = User.find_by(email: params[:email])

  if user&.authenticate(params[:password])
    @session = user.sessions.create!
    cookies.signed.permanent[:session_token] = { value: @session.id, httponly: true }
    redirect_to logged_path(user)
  else
    redirect_to sign_in_path, inertia: { errors: "Credenciais Inválidas" }
  end
end

Expected Behavior

In version 3.3.0, passing a plain string in the errors key worked without issues. It’s expected that inertia should continue supporting plain strings as valid values in the inertia data payload.

Actual Behavior

In version 3.4.0, it appears inertia now expects the errors value to be a hash. Passing a plain string raises a NoMethodError.

[skryukov]

@PedroAugustoRamalhoDuarte good catch!

The thing is, frontend Inertia adapters define errors as a hash (see details here: inertiajs/inertiajs.com#369).

Should we add a warning about passing non-hashable values? 🤔

cc @bknoles

[PedroAugustoRamalhoDuarte]

@skryukov thanks for the explanation, i think it make sense to be a hash by default

[bknoles]

Should we add a warning about passing non-hashable values? 🤔

You mean raising an exception with a more helpful message yea? (the alternative being something like a logger warning)

[bknoles]

merged! will be in the next release. @skryukov 's fix adds graceful nudge towards passing a hash rather than sticking with the stricter enforcement-by-exception!