I try to use :rpc.call to create an entity on another node like this:
:rpc.call(:node@me, MyApp, :create_toto, [%{}])
create_toto builds a changeset for Toto Schema and calls Repo.insert.
When the changeset is valid, everything is ok and the result is as expected.
But when the changeset is not valid, i get this error:
{:error,
%Inspect.Error{
message: "got UndefinedFunctionError with message \"function Toto.__schema__/1 is undefined (module Toto is not available)\" while inspecting %{__struct__: Ecto.Changeset, action: :insert, changes...... }}
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.
# 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.
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??
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…
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.
It really was this and helped me to find out the real problem. The node that called the remote function was trying to cast the changeset (wich was a changeset error) to a string.