We intend to make a decision about this PR before the next planned release but feedback loop might be a bit slower than usual during the summer so please have patience.

The test case gen_server_incorrect_args in behaviour_SUITE in dialyzer fails with your branch:

{test_server,ts_tc,1529}
{test_case_failed,{differ,[{new,4, "gen_server_incorrect_args.erl:7: The inferred return type of handle_call/3 ({'no'} | {'ok'}) has nothing in common with {'noreply',_} | {'noreply',_,'hibernate' | 'infinity' | non_neg_integer() | {'continue',_}} | {'reply',_,_} | {'stop',_,_} | {'reply',_,_,'hibernate' | 'infinity' | non_neg_integer() | {'continue',_}} | {'stop',_,_,_}, which is the expected return type for the callback of the gen_server behaviour\n"}, {old,4, "gen_server_incorrect_args.erl:7: The inferred return type of handle_call/3 ({'no'} | {'ok'}) has nothing in common with {'noreply',_} | {'noreply',_,'hibernate' | 'infinity' | non_neg_integer()} | {'reply',_,_} | {'stop',_,_} | {'reply',_,_,'hibernate' | 'infinity' | non_neg_integer()} | {'stop',_,_,_}, which is the expected return type for the callback of the gen_server behaviour\n"}]}}

@IngelaAndin fixed and force pushed, thanks!

Sorry about the delay, but another test case fails and I did not see that until now. It is a white box test case in stdlib - erl_internal_SUITE:behav that probably needs {handle_continue, 2} appended to the return value of optional_callbacks(gen_server).

@RaimoNiskanen no worries! I will gladly look into it later today.

@RaimoNiskanen fixed and force pushed. I re-ran the stdlib_SUITE here too and everything looks good locally.

On one of our challenged machines this fails:

FROZ
FROZ
FROZ

*** CT Error Notification 2017-07-31 23:36:54.881 ***
gen_server_SUITE:continue failed on line 485

=== Ended at 2017-07-31 23:36:54
=== Location: [{gen_server_SUITE,continue,485},
              {test_server,ts_tc,1529},
              {test_server,run_test_case_eval1,1045},
              {test_server,run_test_case_eval,977}]
=== Reason: no match of right hand side value 
                 [{<0.4970.4>,before_continue},{<0.4970.4>,continue}]
  in function  gen_server_SUITE:continue/1 (gen_server_SUITE.erl, line 485)
  in call from test_server:ts_tc/3 (test_server.erl, line 1529)
  in call from test_server:run_test_case_eval1/6 (test_server.erl, line 1045)
  in call from test_server:run_test_case_eval/9 (test_server.erl, line 977)

I'd say it is because the tested server bangs before_continue to the caller, after_continue to self() and then continue to the caller. Thereafter the server should receive after_continue from itself and bang after_continue to the caller. The caller checks for all 3 messages but did not get the last, possibly due to scheduling.

I do not understand what the started_p call is supposed to do here. Is it maybe trying to check that the continuation loop is not interrupted? But how? Or what?

Note that message ordering is only guaranteed to be preserved between pairs of processes, so a message to self() is not guaranteed to arrive before a subsequent request and reply from another process. {self(),self()} is a different pair than {self(),Other} and {Other,self()}.

I see the race condition. gen_server:call(started_p) is invoked before the process sends the after_continue message to itself. I have changed the tests to no longer rely on started_p as a synchronization mechanism and rather send an ack message after all continue callbacks have been invoked.