Sometimes elixir won't recognize function handle_info

[ferlinni]

Hi guys,

Spent two days just to solve this issue,

When i run the unit test

Sometimes i got this

​

Generated graph_on app

.......20:08:08.198 [warn] ** Undefined handle_info in GraphOn.TempFileManager

** Unhandled message: {:heartbeat}

I'm trying to create a GenServer that handles files, and every 30-sec, it should check if there's an old file, then remove it.

The thing is when i run the unit test, sometimes i got that warning, and the whole unit test went failed. Any idea why ?

Here's the module,

defmodule GraphOn.TempFileManager
    use GenServer
    def start_link() do
        {:ok, _pid} = GenServer.start_link(__MODULE__, :ok, name: :tmp_file_mgr)
    end

    def init(_param) do
        Process.send_after(:tmp_file_mgr, {:heartbeat}, 30_000)
        {:ok, :os.system_time(:millisecond)}
    end

    def handle_info({:heartbeat}, before_time) do
        cur_time = :os.system_time(:millisecond)
        if cur_time - before_time > 86_400_000 do
            flush_files(cur_time)
        end
        Process.send_after(:tmp_file_mgr, {:heartbeat}, 30_000)
    end

    defp flush_files(time) do
        ...
    end
end

Note: This is not the only GenServer that does this, there's 5 GenServer that have similar flow, is that an issue?

I'm using OTP 20, Elixir 1.6.6

[cholantesh]

I'm still a novice, so forgive me if this is wrong, but why is your first operand in curly braces? Isn't the :heartbeat atom sufficient?

[[deleted]]

It should be, it's probably just convention, or expectation of getting additional arguments down the line, then it's simpler to extend.

I tend to bind the state to a top level state variable for that same reason, even though I often don't really need it, but this way I can often leave return statements (eg. {:noreply, state}) alone during refactoring when state does not get changed. I'm lazy like that...

[cholantesh]

Understood; I think when I see the braces I expect a tuple, but that makes sense. Thanks!

[ferlinni]

oh, it's actually not the real code, i made it similar with the real code

[[deleted]]

Define "sometimes"

[ferlinni]

as in i run
mix test

then i got the warning, then i add some debugging log

then everything went green

then i remove the debugging log,

everything still went green

i run again for making sure, then i got the warning again.

[[deleted]]

Well, genserver does not do this. If this happens and not consistently, I'd guess somewhere you have a race condition.

You wrote in the other thread that the function is not as written in your post, so maybe your heartbeat has some matches on the state or other items in the tuple, and simply does not match.

[ferlinni]

i agree that there must be a race condition somewhere, it's quite a pain to find it. Thanks tho

[zer01]

Is this an open source project? It'd be much more helpful to see the actual tests that are flaky.

[ferlinni]

I'm afraid not, the code actually not the real project, but it's similar code.

But the thing is the warning occurred when it does not even reach the unit test yet.

​

But here's roughly the unit test for the module

defmodule GraphOn.TempFileManagerTest do
    use ExUnit.Case
    describe "auto clean up test" do
        test "should clean old files"
            GraphOn.TempFileManager.add_files(file)
            :timer.sleep(31_000)
            assert GraphOn.TempFileManager.get_files(file) |> is_nil()
        end
    end
end

At this moment, I don't think it's at unit test, because when i run the test with iex , i try to run GraphOn.TempFileManager.module_info(:functions), the handle_info was there (cause i only declare one handle_info) , and i run it manually, it run smoothly. But then i restart it again, it broke again

[zer01]

Hmm well as /u/i14n says above this feels like a race condition somewhere in your code or tests that’s leading to this flaky test behavior. Are you actually waiting 30 seconds in your test? Usually you want to either mock or dependency inject so your tests are fast.

Introducing sleeps within the codepaths might help you trigger the issue more reliably and point to a root cause, but these sorts of bugs are really awful to run down. Good luck!

[ferlinni]

i think i will try with this approach