Your solution of calling the function before passing the children to Supervisor.start_link is totally reasonable, and is what Sentry does to set up its’ Logger backend. However, you’ll need to make sure that whatever lib you’re using to make the HTTP request is started before you make the call! Req might do this for you automatically (guessing yes) but I know Finchwon’t, as it must be started by the client app.
Thanks, good to get some confirmation on my approach. In my case, it should be fine – I’m doing some more complex RabbitMQ setup that gets a little hard to follow if it’s strung across so many Broadway pipelines and their :after_connect arguments.
However, that is an interesting point… sometimes you need certain things started in order (like the HTTP client example). Is there any way to ensure an ordered startup like that (with blocking)?
I’d say this is more of a smell than anything. Your applications shouldn’t be coupled in that way, and if they are, then Worker2 should be having Worker1 in its’application.ex
There are two main approaches to this. One is to do whatever you need to do in the application start/2 callback which you’ve already discussed. This is good if you need to do something before any process has started.
If you need some parts of the application to be started (e.g. Ecto) then you’ll need to add a process to your supervisor that performs the setup after the needed processes are started but before the processes that require the setup step.
I use the latter approach to ensure all Ecto connections have been established before moving on to starting something like Oban. What I’ve done is created a transient GenServer that performs the blocking work in the init/1 callback. This will halt the supervisor start process until the work in init/1 has finished. Once the work in init/1 has finished I return :ignore to prevent the GenServer from starting and continue on with starting the remaining processes.
Whether this is a code smell or not I’ll let you decide.
Here is some example code.
defmodule MyStartupProcess do
use GenServer, restart: :transient
def start_link(_opts) do
GenServer.start_link(__MODULE__, :ok)
end
@impl true
def init(_) do
:ok = do_setup()
:ignore
end
end
I think you should either just do something in an init callback of your own GenServer or just use a handle_continue in it – assuming that the latter will not leave your app in an inconsistent state until your own init code succeeds.
You wouldn’t want to use handle_continue in this case because handle_continue will explicitly not block startup, although in my experience most of the time you actually don’t want to block startup. But this thread is specifically about the times that you do want to block startup.
Yeah I get this, and I am questioning the need to block startup. But it’s also true that it’s more complex to have both: (1) not block startup and (2) not have your app in degraded state, so maybe blocking startup really does save time and effort.
Well, AFAIK the app children are started sequentially, in the order they are specified, so you can start enough to make sure your initialization code will not fail and then do the blocking operation in your GenServer’s init callback?