Ceph » RADOS

We are running ceph 13.2.5 on Centos Linux 7.5.1804, and the ceph cluster consists of 5 ceph-mon. Every 30 seconds, we modify a couple of keys in the config-key. And we noticed that the ceph-mon failed several times.
The traceback shows below.

0> 2019-04-25 13:17:18.708 7fe4870cc700 -1 /home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/cent
os7/MACHINE_SIZE/huge/release/13.2.5/rpm/el7/BUILD/ceph-13.2.5/src/mon/Paxos.cc: In function 'MonitorDBStore::TransactionRef Paxos::get_pending_transaction()' th
read 7fe4870cc700 time 2019-04-25 13:17:18.707278
/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/huge/release/13.2.5/rpm/el7/BUI
LD/ceph-13.2.5/src/mon/Paxos.cc: 1559: FAILED assert(pending_finishers.empty())

ceph version 13.2.5 (cbff874f9007f1869bfd3821b7e33b2a6ffd4988) mimic (stable)
 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0xff) [0x7fe494e3afbf]
 2: (()+0x26d187) [0x7fe494e3b187]
 3: (Paxos::get_pending_transaction()+0xf7) [0x560e85393ba7]
 4: (ConfigKeyService::store_put(std::string const&, ceph::buffer::list&, Context*)+0x36) [0x560e85346ba6]
 5: (ConfigKeyService::service_dispatch(boost::intrusive_ptr<MonOpRequest>)+0xab6) [0x560e85349576]
 6: (Monitor::handle_command(boost::intrusive_ptr<MonOpRequest>)+0x1faf) [0x560e852b817f]
 7: (Monitor::dispatch_op(boost::intrusive_ptr<MonOpRequest>)+0x39d) [0x560e852bcbad]
 8: (Monitor::C_Command::_finish(int)+0x5c) [0x560e852f729c]
 9: (C_MonOp::finish(int)+0x43) [0x560e852c07d3]
 10: (Context::complete(int)+0x9) [0x560e852bf9e9]
 11: (void finish_contexts<Context>(CephContext*, std::list<Context*, std::allocator<Context*> >&, int)+0x93) [0x560e852c7513]
 12: (Paxos::restart()+0xe3) [0x560e85393733]
 13: (Monitor::_reset()+0x17e) [0x560e8528b0ce]
 14: (Monitor::join_election()+0x35) [0x560e8528b1f5]
 15: (Elector::bump_epoch(unsigned int)+0x147) [0x560e853258c7]
 16: (Elector::handle_propose(boost::intrusive_ptr<MonOpRequest>)+0x6b0) [0x560e853267f0]
 17: (Elector::dispatch(boost::intrusive_ptr<MonOpRequest>)+0x449) [0x560e85327f09]
 18: (Monitor::dispatch_op(boost::intrusive_ptr<MonOpRequest>)+0xbbb) [0x560e852bd3cb]
 19: (Monitor::_ms_dispatch(Message*)+0x732) [0x560e852be212]
 20: (Monitor::ms_dispatch(Message*)+0x23) [0x560e852e3cf3]
 21: (DispatchQueue::entry()+0xb7a) [0x7fe494ef739a]
 22: (DispatchQueue::DispatchThread::entry()+0xd) [0x7fe494f952cd]
 23: (()+0x7dd5) [0x7fe49417ddd5]
 24: (clone()+0x6d) [0x7fe490a98ead]
 NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.

I guess the assert failed when the paxos restart procedure is doing "finish_contexts(g_ceph_context, committing_finishers, -EAGAIN)" while pending_finishers is not empty.
And I found something interesting, in Paxos::shutdown, the sequence is:

finish_contexts(g_ceph_context, pending_finishers, -ECANCELED);
          finish_contexts(g_ceph_context, committing_finishers, -ECANCELED);

while in Paxos::restart, the sequence is:

finish_contexts(g_ceph_context, committing_finishers, -EAGAIN);
          finish_contexts(g_ceph_context, pending_finishers, -EAGAIN);

Should not the pending_finishers always be handled before committing_finishers?