Difficulty figuring out DynamicSupervisor :invalid_child_spec error

Really? Where is the :id in the error message?

If those other values I didn’t add really are coming from the validate_child/1 call matching the map version… I wouldn’t expect to see :id. The signature of that function is:

validate_child(%{id: _, start: {mod, _, _} = start} = child)

The :id value is explicitly ignored and I wouldn’t expect to see it in the error. In the child spec that I’m passing, the :id value is there.

But this is the issue. In reality I expect that I’m not hitting that validate_child/1 function which matches on the child spec map… but somewhere I’m getting most of the extra values which aren’t in my child spec defaulted in and that’s the only place I see where it might come from … so its as though I’m hitting it… I just don’t see how that’s possible.

Interestingly, the error child spec is given as a tuple, not a map. So I’m digging right now to see how that might be possibly happening. My sense is that maybe I’m not finding all the places where :invalid_child_spec may be coming from.

My apologies… this is a silly statement on my part considering the match on child is what is used in the meat of that function… but in the end it doesn’t do anything with :id anywhere anyway… it doesn’t pass it on into the subsequent calls.

Look at the back trace. You are not passing the right child_spec and the function balked. Add logging at the right place if necessary.

I’d suggest tracing the functions involved and see if the correct values reach the places you expect them to reach.

This is peculiar - it looks like the result of validate_child/6 has somehow ended up as the input of validate_child/1

I don’t understand how this could be happening - the only place that calls validate_child/1 is start_child, and that’s guarded to only allow in 6-tuples or maps. Passing a 5-tuple to start_child would give an ArgumentError in Supervisor.child_spec/2 before it even made it to validate_child.

Right. I assume that’s the case. But I can’t see how that original child spec is invalid. My looking through the Elixir code was an effort to figure out what I’m doing wrong in the child spec… but I can’t line up what the child spec is with the result that Elixir is producing.

Good tip. I know that my understanding of Elixir/Erlang debugging, tracing, and monitoring is underdeveloped… and this is very helpful. I wasn’t aware of this tool and I think it could be what I need to at least.

Naturally, I couldn’t understand it either… but the extrace tip from @LostKobrakai is getting me going in the right direction. What I’ve found so far is that the child spec I’m submitting appears to actually be passing the validate_child/1 (map match) and validate_child/6 successfully. I don’t appear to actually be getting to:

defp validate_child(other) do
  {:invalid_child_spec, other}
end

The error is coming from somewhere else.

The reason we see a 5 tuple is because that’s what validate_child/6 produces:

defp validate_child(start, restart, shutdown, type, modules, significant) do
    with :ok <- validate_start(start),
         :ok <- validate_restart(restart),
         :ok <- validate_shutdown(shutdown),
         :ok <- validate_type(type),
         :ok <- validate_modules(modules),
         :ok <- validate_significant(significant) do
      {:ok, {start, restart, shutdown, type, modules}}
    end
  end

This ultimately gets passed to DynamicSupervisor.call/2 which in turn calls GenServer.call/3. So in the trace I see:

GenServer.call(:"MscmpSystSettings.TestSupportSupervisor", {:start_child,
 {{MscmpSystSettings, :start_link,
   [
     :"MscmpSystSettings.TestSupportService",
     {:via, Registry,
      {MscmpSystSettings.TestRegistry, "0000mt.tstspt.MscmpSystDb.ContextRole"}},
     []
   ]}, :permanent, 5000, :worker, [MscmpSystSettings]}}, :infinity)

… and that’s as far as I’ve gotten. They key point is that, at least to this point I’m passing the child spec validation step enough for the GenServer.call/3 attempt.

I’m not done troubleshooting it yet, but at this point I’m not stuck.

You already had good answers and they sadly have not helped – IMO the next logical step is to make a reproducible example in a singular file that’s using Mix.install?

The other place that :invalid_child_spec could come from is in :supervisor.handle_call’s :start_child clause:

https://github.com/erlang/otp/blob/64fcd877c7645cea51e0b532255cc602f6e9aad5/lib/stdlib/src/supervisor.erl#L998-L1005

The only way I could see this happening is calling DynamicSupervisor.start_child with a name or PID that’s actually running :supervisor code.

Quite the contrary. I agree I’ve gotten good answers… and they have helped me on this problem immensely. Enough so that I think I can solve the problem without additional help. This is why I mentioned I’m no longer stuck.

Benjamin’s advice regarding tracing and pointing me to that extrace utility was sufficient to break the mental block that I couldn’t get past: I assumed my child spec had to be wrong and the place where it had to fail was in the validate_child functions of DynamicSupervisor: extrace showed me that my child spec was not failing were I was stubbornly believing it must be; the ability to trace through Elixir private functions has made the most difference. While I haven’t found the problem yet, that’s now more about my personal stamina to pursue it further today than missing the knowledge to figure it out… I’m quite sure I’ve got what I need now to solve the problem at this point.

And while Matt’s answer didn’t directly get me on the right path… he at least gave me some comfort that I might not be a complete moron in my reading of the issue. Matt’s answers in this community are regular and of consistently high quality… that his reading was similar to mine gave me hope that I was being somewhat reasonable.

You’re no slouch either … but this time I have to both agree and disagree with you.

If I get to the root cause, I’ll post what I find here for the record in case it might help others. I have some suspicions about what might be wrong, but I’ll wait until I’ve completed the troubleshooting.