crimson/osd: complete PGAdvanceMap's pg-deleted path properly

When the pg has been deleted while PGAdvanceMap was queued, start()
takes an early return and skips the map-advance loop. The PeeringCtx
handed to the operation may already carry a transaction and queued
peering messages, so returning without calling complete_rctx() would
drop them. Dispatch the rctx before bailing out.

Also leave the PGPeeringPipeline::process stage via handle.complete()
instead of relying on the exit_handle defer's handle.exit(). The
pg-deleted path is a graceful completion, not an op failure, so it
should match the normal completion path; handle.exit() is documented
for the failure case only.

Signed-off-by: Kefu Chai <tchaikov@gmail.com>

diff --git a/src/crimson/osd/osd_operations/pg_advance_map.cc b/src/crimson/osd/osd_operations/pg_advance_map.cc
index d22e42926d855d06b9c0775d809314afcf588040..0c58cecee74d98c9c86176f6d2fa8d32d9140eeb 100644 (file)
--- a/src/crimson/osd/osd_operations/pg_advance_map.cc
+++ b/src/crimson/osd/osd_operations/pg_advance_map.cc
@@ -71,6 +71,9 @@ seastar::future<> PGAdvanceMap::start()
   // pg may have been deleted while this op was queued; see PG::do_delete_work.
   if (pg->is_deleted()) {
     DEBUG("{}: pg is deleted, skipping advance", *this);
+    co_await pg->complete_rctx(std::move(rctx));
+    co_await handle.complete();
+    exit_handle.cancel();
     co_return;
   }