Why :rpc.call: returns an Inspect.Error?

Does :create_toto resides in MyApp?
I think you should be passing something like MyApp.Toto as the second argument or Toto, idk:
:rpc.call(:node@me, MyApp.Toto || Toto, :create_toto, [%{}]).

The second argument should be the module that defines the function you’ll be calling.

Yes, create_toto is a very basic function of the MyApp module like this:

def create_toto(%{} = attrs) do
     Toto.changeset(%Toto{}, %{age: 12}) |> Repo.insert()
end

And Toto is an alias?

Also, could you put all the code involved here? Might be easier seeing everything.

Okay, i give a try report it simply:

# my_app.ex
defmodule MyApp do
  alias MyApp.Toto
  alias MyApp.Repo

  def create_toto(%{} = attrs) do
     Toto.changeset(%Toto{}, %{age: 12}) |> Repo.insert()
  end
end

#my_app/toto.ex
defmodule MyApp.Toto do
  use Ecto.Schema

 schema "totos" do
   age: :integer

  timestamps()
 end

def changeset(toto, attrs) do
  too
 |> Ecto.Changeset.cast(attrs, [:age])
 |> Ecto.Changeset.validate_required([:age])
end

end

I am writting this code here for the report. It is not the real code but it allows to understand what is going on.

This app runs on a node A.
The second node try to call like this

:rpc.call(:nodeA@me, MyApp, :create_toto, [%{}])

and on changeset error, get the {:error, %Inspect.Error{}..}

Is the second node the same app as on node A or a different one?

I’m not sure how rpc deals with function calls that invoke functions from other modules. I only ever called functions that don’t rely on other modules.

But from the looks of it, it does not have MyApp.Toto available. Maybe try importing the MyApp.Toto module.

I found that if i don’t run :rpc.call from an app, a.k.a, execute directly

~ $ iex --sname lol --cookie MYCOOKIE

i get something like

iex(lol@binary)1> :rpc.call(:my_app@me, MyApp, :create_toto, [%{}])
{:error,
 %{
   __struct__: Ecto.Changeset,
   action: :insert,

So it seems that the :rpc.call caller try to inspect the changeset.

The changeset seems to be inspected with structs: false.

But why and were it is done?

My real problem is that i have problems when i get changeset errors from another node.

The calling node is trying to inspect the Ecto.Changeset, which has a custom Inspect protocol implementation that in turn is trying to render the Toto struct that’s embedded inside it. It seems that it does not consider the possibility that the :data field in the changeset is a struct from a module that doesn’t exist locally.

(Edit: it is trying to call __schema__/1 on that module here)

To prevent the error, force the local console to not try and call the Ecto.Changeset inspect implementation, for example by calling IEx.configure(inspect: [structs: false]) before the :rpc call.

Alternatively you could monkey-patch Ecto.Changeset from within iEx:

defimpl Inspect, for: Ecto.Changeset do              
  defdelegate inspect(data, opts), to: Inspect
end

Hi
thank you for the response.
I wonder who is doing the inspect and when it occurs.
And does it means we cannot rely on remote node creation via changeset??

Does that mean that an ecto.changeset error cannot be passed between nodes ?

IEx on the local node is calling inspect on the value returned by :rpc.call/4. So by that time the RPC itself was completed, the exception happens locally in the console.

The RPC worked just fine, and if the call didn’t happen in the console but in some local code, you could process the returned changeset normally. It’s just the rendering in the console that fails in this case. You would have similar problems if you were to try and log the changeset, for example.

You could open a ticket on Ecto to see if the team might consider handling this more gracefully. The question then is what fields should be redacted, because that’s what the custom Inspect protocol is trying to do: hide sensitive data. If the struct is not known locally, how can the changeset inspection decide which fields to show? Should it redact all fields, out of an abundance of caution? Maybe…