Fl4m3Ph03n1x
Put simple module in supervision tree?
Background
I have a module that reads information from a CSV file and puts it in memory. As with all modules that read things from files, there are a myriad of errors that can occur (file missing, corrupted file, permissions, etc).
This module is critical to the application. Without it, the application does nothing. I need to know of a way to startup the application while being able to test it’s startup.
Code
This is the code as I have envisioned:
defmodule Engine.Application do
use Application
#module that reads data from file and puts it into memory. Nothing special.
alias Engine.Populator
def start(_type, _args) do
children = []
opts = [strategy: :one_for_one, name: Engine.Supervisor]
case Populator.init("super_duper_file.csv") do
{:ok, :start_success} -> Supervisor.start_link(children, opts)
{:error, :reason1} -> IO.puts("Fix it by doing something you dummy!")
{:error, :reason2} -> IO.puts("We could do something, but I'm too lazy")
err -> IO.puts("¯\_(ツ)_/¯")
end
end
end
However, this code can’t be tested. I can’t test what happens if Populator.init fails with :reason2 because to do it I need to create a test that invokes Engine.Application.start, which mix has already invoked to run said test (so it will always fail with :already_started error).
Question
So I take it this logic shouldn’t probably be here. Someone suggested I should turn this into something supervised, and that is what I am trying to do.
But I can’t find a logical way to turn a module that simply reads data from a file into something that is it’s own supervised process. I also want to have decent error messages instead of having the app just blow into my face.
How can I fix this?
Marked As Solved
benwilson512
That’s exactly correct. There’s a bunch of handy features here. For example to support your test code:
def start_link(opts) do
if Application.get_env(:my_app, :start_populator) do
GenServer.start_link(__MODULE__, opts, [])
else
:ignore
end
end
If start_populator is false (in your test.exs for example) then it just ignores it and doesn’t try to start it in the supervision tree. This lets you test error or success cases in your test cases themselves without causing issues with application start.
Also Liked
david_ex
You should be able to simply put it in the list of children: children = [Populator] and remove the whole case block. If the Populator’s init succeeds, the supervisor will ensure it keeps running, and if not the supervisor won’t start up. Then, you only need to test Populator.init/1 to ensure it returns the correct ok/error tuple based on the params it receives.
But I can’t find a logical way to turn a module that simply reads data from a file into something that is it’s own supervised process.
If by “simply reads data” you mean it’s simply a library of functions, then it doesn’t need to be supervised. If it has its own state (e.g. it’s a GenServer), then it’s already ready to be put in a supervision tree as above (the use statement will generate a child_specification function for you).
Finally, it appears you’re not designing your service as recommended: it should always be able to start (i.e. return an {:ok, _} tuple) even when nothing else works, and should return an {:error, _} only if it really cannot start up). From there, you can move up levels as more things work (e.g. the internal status goes from :not_ready_reason_1, to :not_ready_reason_2, to finally :ready and it will return {:error, :not_ready_reason_1 | :not_ready_reason_2} unless it’s status is :ready where it would return the result of the parsing). See also It's About the Guarantees
NobbZ
What part of memory is populated? An ETS table? Who owns it? A GenServers state? This should be supervised then… Some Port? It has to have an owning process as well… And any of the owning processes should be supervised…
benwilson512
GenServers have two characteristics about them: #1 they can hold state, and #2 they’re the simplest OTP compliant process. Normally all the attention goes to #1, but #2 is relevant here when we’re talking about initializing something. If you want to initialize something, in particular :ets or :persistent_term at a specific point in your supervision tree, you need an OTP compliant process to do this.
In the case of :ets you then need that process to stick around so that it can own the table. In the case of :persistent_term you could just shut the process down after it’s initialized things, or leave it around so you can message something to reinitialize if you wish. Either way, we’re using a genserver more for it’s ability to be a good supervision tree citizen then we are for its long term state management.
benwilson512
@david_ex’s answer is great, I’ll just add that you should probably have your Populator init function take an argument that lets you bypass doing any actual work. Then your supervision tree would look like:
[
{Populator, Application.get_env(:my_app, :populator_config)}
]
In test environment set populator_config to be :fake or whatever. BUT then in your test code you can call Populator.init(real_param) to do a real test.
benwilson512
If it has to read a file on boot it does have state, even if that state is “the file exists”.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers. By developers, for developers.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"