First off the disclaimer: I've used AI tools a lot to help me investigate this. I did my due diligence, but I do apologise if this turns out to be not what it is.
With that being said, I believe that Horde.Registry appears to have a race in the :gen_statem startup path when using :via names. This issue doesn't not happen with GenServer (or :gen_server for that matter)
I've put a small script (with the help of AI) that explains the issue and reproduces it: https://gist.github.com/infinityfye/55d02dda7e59856c69e4584764e31b18
On a single node, :gen_statem.start/4 intermittently fails with {:process_not_registered_via, Horde.Registry}. I think the issue is that register_name/2 can return success before the CRDT diff has been applied to ETS; then :gen_statem immediately resolves the name during startup and gets :undefined.
I understand Horde’s cross-node eventual consistency model; this looks like an intra-node startup ordering issue within a single start call.
And, again, this never happens with Genserver/:gen_server. This is because they work slightly differently in erlang/otp itself. I've expanded on this a little in the gist.
Expected: once register_name/2 succeeds during startup, immediate name resolution in that startup path should also succeed.
Actual: intermittent startup failure with {:process_not_registered_via, Horde.Registry}.
Please let me know if there is anything I can do to make this more reproducible or help in any way.
First off the disclaimer: I've used AI tools a lot to help me investigate this. I did my due diligence, but I do apologise if this turns out to be not what it is.
With that being said, I believe that
Horde.Registryappears to have a race in the:gen_statemstartup path when using:vianames. This issue doesn't not happen withGenServer(or:gen_serverfor that matter)I've put a small script (with the help of AI) that explains the issue and reproduces it: https://gist.github.com/infinityfye/55d02dda7e59856c69e4584764e31b18
On a single node,
:gen_statem.start/4intermittently fails with{:process_not_registered_via, Horde.Registry}. I think the issue is thatregister_name/2can return success before the CRDT diff has been applied to ETS; then:gen_statemimmediately resolves the name during startup and gets:undefined.I understand Horde’s cross-node eventual consistency model; this looks like an intra-node startup ordering issue within a single start call.
And, again, this never happens with
Genserver/:gen_server. This is because they work slightly differently in erlang/otp itself. I've expanded on this a little in the gist.Expected: once
register_name/2succeeds during startup, immediate name resolution in that startup path should also succeed.Actual: intermittent startup failure with
{:process_not_registered_via, Horde.Registry}.Please let me know if there is anything I can do to make this more reproducible or help in any way.