CQv2: Small fixes of and via the property suite

This commit is contained in:
Loïc Hoguin 2022-09-05 09:41:34 +02:00
parent f3963a5998
commit 8051b00305
No known key found for this signature in database
GPG Key ID: C69E26E3A9DF618F
2 changed files with 11 additions and 1 deletions

View File

@ -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

View File

@ -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, _}, _) ->