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?

10 comments

#supervision-tree #application

0 1532 10

2019-07-11 14:59:22 UTC

Marked As Solved

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

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.

Post #11

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

Post #2

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…

Post #6

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

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.

Post #9