test(mapoi_server): ノード破棄を context shutdown 後に集約し tf2 の join デッドロックを回避

[kimushun1101]

Fixes #461

背景

週次 schedule の build-test (lyrical) が colcon test でタイムアウト失敗した
(該当 run)。
test_nav2_bridge_unit が ctest の 60 秒上限に到達し、結果ファイルも生成されなかった。

ログの内訳は [ RUN ] 15 回 / コンストラクタ完了ログ 15 回 / [ OK ] 14 回。
15 個目のテスト本体は static 純関数への EXPECT_TRUE 1 行で node_ すら参照しないため、
止まっていたのは本体ではなく TearDown() の node_.reset() だった。

原因

MapoiNav2Bridge のコンストラクタは単引数版 (= spin_thread=true) の TransformListener を作る。
これは内部ノードと専用 executor スレッドを持ち、デストラクタで cancel() → join() する。

ここに未修正の upstream race がある。

• TransformListener hangs in destructor when using dedicated thread ros2/geometry2#517 (open, 2022-04 起票)
• cancel() が専用スレッドの spin() 開始前に走ると cancel シグナルが失われ join() が永久ブロックする
• 修正候補 PR Added additional flag to fix race condition in TransformListener ros2/geometry2#518 と
  Fixed deadlock in destructor in TransformListener ros2/geometry2#752 はいずれも未マージ。
  humble と rolling でデストラクタ実装は同一で、両方とも未修正

生成直後に破棄される短命な listener ほどこの窓に嵌まる。
Nav2BridgeTestFixture は毎テスト MapoiNav2Bridge を生成・破棄しており、
1 run あたり 69 回の発火機会があった。各テストは 15–23 ms と短命で、窓に正確に嵌まっていた。

lyrical / humble の既定 RMW はどちらも rmw_fastrtps_cpp で、distro 差ではなく確率的な発火。
CPU が逼迫する CI ランナーで顕在化する。

変更

本番コード (mapoi_server/src/) は変更していない。テストのノード寿命管理だけを直した。

1. Nav2BridgeTestFixture からノード生成を撤去した。rclcpp::init の保証だけを残す。
   このフィクスチャを使う 45 テストはノードを参照していなかった。
2. node_ を必要とする 13 テストは、新しい Nav2BridgeNodeFixture でスイート内 1 個を共有する。
   共有に伴う順序依存は、各テスト冒頭で前提を明示的に初期化して潰した。
3. 生成したノードは共有ノードも含めてすべて retain_node() で保持し、破棄を
   global test environment の TearDown() に集約する。そこでは
   rclcpp::shutdown() を先に呼んでから破棄する。context が無効になれば
   Executor::spin() のループ条件が偽になるため、cancel シグナルの取りこぼしに関係なく
   ~TransformListener() の join() が戻る。

つまり残った 12 回の生成についても、破棄はすべて context shutdown 後に行われる。
race は確率的に減るのではなく構造的に起きなくなる。

実測

lyrical コンテナを 2 CPU に制限し、ビジーループ 2 本で飽和させた状態で、
ctest と同じ 60 秒 timeout・単発実行 (gtest_repeat なし) を試行した。

	生成	shutdown 前に破棄されるノード	ハング
main	69	69	4 / 60
手順 1–2 のみ	12	11	1 / 60
本 PR	12	0	0 / 100

ハング位置は保全ログから特定した。main では AngleDiffAbsZero や BuildRoutePoiNamesEmpty など
フィクスチャがノードを作っていたテストで、手順 1–2 だけの版では ConstructorTwistParamCreatesTwistSub など
本体でノードを作るテストで詰まっており、いずれも該当テストの所要が 59.9 秒に膨れていた。
短命破棄の件数とハング率が対応しており、機構と整合する。

検証

humble / jazzy / lyrical の 3 distro で以下を確認した。

• colcon build と colcon test --ctest-args -LE launch_test + colcon test-result --verbose が green
• テストケース数 58 で変更前と一致 (取りこぼしなし)
• --gtest_shuffle --gtest_repeat=3 が green (共有ノードに順序依存が無いこと)
• ノード生成回数が 69 → 12 (共有 1 + コンストラクタ検証 11)

補足

ctest の timeout 延長や #ifdef UNIT_TEST による本番コードへの分岐追加は採らなかった。
前者は真のデッドロックに効かず、後者はテストした物と出荷する物が別になるため。

TransformListener を spin_thread=false にする案も見送った。本番の TF 更新スレッド構成が変わり、
select_map_callback が default group を最大 ~11s 塞ぐ設計 (#213) と干渉するため、
CI flake 対策とは切り分けるべきと判断した。

ノードを retain した結果、共有ノードと AutoResumeTimeout* のノードが既定 cmd_vel を
binary 終了まで掴み続ける。constructor test を追加する際は従来どおり専用 cmd_vel_topic が必要で、
その理由をコメントに明記してある (#249)。

work in .my_brain