Add a standard "ping" for processes?

Erlang/OTP Proposals Proposals: Ideas
1

Question from Elixir land. I have a GenServer that receives a cast message and performs a side effect (a database update). In a test, I want to send the cast, wait “long enough”, then confirm that the side effect happened.

Some options for waiting “long enough”:

  1. Process.sleep/1 - bad because if it’s too short, the test will not consistently pass, but if it’s too long, the test will be slow. Also, the tests run slower in CI, which makes picking the right value tricky. A variant of this would be repeated, short “sleep and check” cycles, up to a timeout.
  2. Modify the GenServer for the sake of the test to notify when it’s finished (eg via telemetry)
  3. Modify the GenServer for the sake of the test to have a handle_call(:ping; when it replies, I’d know the prior message in the mailbox had been processed too
  4. Use a standard, mailbox-dependent call like :sys.get_state/1 or :sys.get_status/1 - same idea as item 3 but no modification of the GenServer is needed. Minor downsides: it’s a bit wasteful since I don’t actually need the return value, and it requires code comments to explain why I’m calling it and ignoring the return value.
  5. Modify the side effect function for the sake of the test to notify that it’s complete

I don’t love modifying code to emit events or handle messages solely for the sake of testing. Option 4 is my current choice, but it would be nice if there were a :sys.ping(pid) that would do the same thing - similar to what we have in Node.ping/1 (although I know that has the side effect of establishing clustering if it’s not already established).

I thought that something like :sys.ping(pid) would probably already exist in Erlang, but if it does, I haven’t found it. Does it exist? If not, should it?

2

you could maybe just change to do something along the lines of

do_stuff({reply, Payload}) ->
    gen_server:call(?SERVER, {do_stuff, Payload});
do_stuff(Payload) ->
    gen_server:cast(?SERVER, {do_stuff, Payload}).

handle_call({do_stuff, Payload}, _From, State) ->
    MyReply = doing_stuff(Payload),
    {reply, MyReply, State}.

handle_cast({do_stuff, Payload}, State) ->
    _ = doing_stuff(Payload),
    {noreply, State}.

So in your test, just use mod:do_stuff({reply, Payload})

3

I’d use the variant of the first version: “sleep and check the side effect” in a cycle. If the environment is fast, only a few checks are necessary and the test finishes fast. If the environment is slow, more checks are done, but it’s still robust.

4

Why not use (the equivalent of) gen_server:call/3 instead? Using polling in this case feels like a kludge.

I.e., I’d go with option 5. Perhaps pass in an optional From in the cast, and when done with the side-effect do a gen_server:reply (or equivalent) if the From is present.

5

I usually use option 4 and, to avoid comments explaining why… I wrap it up in a properly named function, like…

wait_for_side_effects(OTPProcess) ->
    _ = sys:get_state(OTPProcess),
    done.
2 Likes
6

Another option can be to use Erlang tracing to know when otherwise unobservable events have happened.

7

Yeah… et for the win!

image
image275×183 58.3 KB

2 Likes
8

I’ve been using telemetry for this. You probably want some metrics anyway, right? So why not take advantage of that in your tests…?

See, for example, kafine/test/kafine_node_consumer_pause_tests.erl at 0.28.0 · happening-oss/kafine · GitHub, in which we start a “node consumer” and then wait until it becomes idle before continuing with the rest of the test.

    TelemetryRef = telemetry_test:attach_event_handlers(self(), [
        [kafine, node_consumer, idle],
        [kafine, node_consumer, continue]
    ]),

    {ok, Pid} = start_node_consumer(?CONSUMER_REF, Broker, TopicPartitionStates),

    receive
        {[kafine, node_consumer, idle], TelemetryRef, _, _} -> ok
    end,

    ?assertMatch({idle, _}, sys:get_state(Pid)),

The other nice thing about this is that you can use the telemetry event’s Measurements and Metadata to “smuggle” useful information back to the test.

9

We use GitHub - kafka4beam/snabbkaffe: Distributed trace-based test framework with fault injection library for this purpose. Though it doesn’t satisfy the requirement

I don’t love modifying code to emit events or handle messages solely for the sake of testing.

…But it is a powerful testing technique otherwise. For example, it allows to correlate effects from different nodes. If you print debug logs after completion of event processing, then you may as well replace them with the snabbkaffe tracepoints and use ?block_until macro to synchronize testcase with the SUT.