CQv2: Small fixes of and via the property suite
This commit is contained in:
parent
f3963a5998
commit
8051b00305
|
|
@ -974,6 +974,12 @@ handle_info(sync, State) ->
|
|||
handle_info(timeout, State) ->
|
||||
noreply(internal_sync(State));
|
||||
|
||||
%% @todo When a CQ crashes the message store does not remove
|
||||
%% the client information and clean up. This eventually
|
||||
%% leads to the queue running a full recovery on the next
|
||||
%% message store restart because the store will keep the
|
||||
%% crashed queue's ref in its persistent state and fail
|
||||
%% to find the corresponding ref during start.
|
||||
handle_info({'DOWN', _MRef, process, Pid, _Reason}, State) ->
|
||||
%% similar to what happens in
|
||||
%% rabbit_amqqueue_process:handle_ch_down but with a relation of
|
||||
|
|
|
|||
|
|
@ -544,7 +544,11 @@ postcondition(_, {call, _, cmd_channel_publish, _}, Msg) ->
|
|||
postcondition(_, {call, _, cmd_channel_publish_many, _}, Msgs) ->
|
||||
lists:all(fun(Msg) -> is_record(Msg, amqp_msg) end, Msgs);
|
||||
postcondition(_, {call, _, cmd_channel_wait_for_confirms, _}, Res) ->
|
||||
Res =:= true;
|
||||
%% It is possible for nacks to be sent during restarts.
|
||||
%% This is a rare event but it is not a bug, the client
|
||||
%% is simply expected to take action. Timeouts are
|
||||
%% always a bug however (acks/nacks not sent at all).
|
||||
Res =:= true orelse Res =:= false;
|
||||
postcondition(_, {call, _, cmd_channel_consume, _}, _) ->
|
||||
true;
|
||||
postcondition(_, {call, _, cmd_channel_cancel, _}, _) ->
|
||||
|
|
|
|||
Loading…
Reference in New Issue