見出し画像
Photo by chic_dekopin

コード見直し学習&フォルダ整理&PJ要約資料作成開始56

Naki

その理解で合っています。
`GEOFENCE_BLOCKED` は「異常通信エラー」ではなく、業務上は正規の拒否結果」です。

つまり、この `bad.geofenceBlocked` は
**「システム障害の bad」ではなく、「分析上の注目サンプル」**として拾っている可能性が高いです。

まずこの条件が見ているもの

obj.msg === "FLIGHT_PLAN_REJECTED" &&
obj.reason === "GEOFENCE_BLOCKED"

これは

  • `msg` は `FLIGHT_PLAN_REJECTED`

  • 理由は `GEOFENCE_BLOCKED`

という意味です。

つまり処理の流れとしては、

  1. フライトプランが来る

  2. geofence判定をする

  3. 飛ばせない空域・条件だった

  4. 意図通り reject する

ということです。

なので「エラー」ではない

ここは大事です。

エラーの例

  • SDSPに接続できない

  • JSONが壊れている

  • 期待した値がない

  • 例外が発生した

こういうのはシステムの不具合・通信障害です。

`GEOFENCE_BLOCKED` の例

  • 飛行計画そのものは届いている

  • geofenceチェックも動いている

  • 判定もできている

  • その結果、ルールにより拒否した

これは業務ルール上の正規結果です。

では、なぜ `bad` に入れているのか

ここが混乱ポイントです。

`bad` という名前のせいで「全部エラー」と見えやすいですが、実際にはここでは

  • 件数を見たいもの

  • 後でサンプル確認したいもの

  • 問題になりやすい拒否理由

  • 運用上の注目イベント

をまとめているだけ、と考えるのが自然です。

つまり `bad.geofenceBlocked` は

「障害ログ」ではなく「拒否の代表例を保存する箱」

です。

たぶん設計意図はこう

たとえば集計結果で

  • geofenceで何件止まったか

  • どの flightPlanId が止まったか

  • traceId で元の流れを追えるか

  • 誰向けに reject したか

を後で見たいわけです。

そのために

pushLimited(bad.geofenceBlocked, {
  flightPlanId: obj.flightPlanId || "(unknown)",
  traceId: obj.traceId || null,
  to: obj.to || null,
});

で代表サンプルを残しています。

`sdspError` との違い

この違いを分けるとかなり整理できます。

`geofenceBlocked`

  • geofence判定できた

  • 結果として拒否

  • 正規処理

`sdspError`

  • geofence判定のためのSDSP通信で失敗

  • 判定そのものが怪しい、またはfallbackに回る

  • 障害寄り

実務的にはどう捉えるべきか

あなたのログ分析では、`bad` を次の2種類に分けて考えると分かりやすいです。

1. 本当に異常・障害寄り

  • `sdspError`

  • `filedTraceMismatch`

  • `filedWithoutPending`

  • `pendingTimeoutRejected`

2. 正規だが要観察

  • `geofenceBlocked`

  • `sdspFallback`

  • `pendingExpired`（文脈による）

`geofenceBlocked` は明らかに後者です。

一言でいうと

`GEOFENCE_BLOCKED` は
**「エラー」ではなく「ルールに基づく拒否」**です。

ただし、分析上は

  • 想定より多すぎないか

  • 特定シナリオで偏っていないか

  • geofence設定が厳しすぎないか

を見たいので、`bad.geofenceBlocked` に入れている、という理解でよいです。

名前として少し誤解を生みやすい

もし整理するなら `bad` よりも、たとえば

const samples = {
  anomalies: { ... },
  rejects: { ... },
  fallbacks: { ... },
};

のように分けた方が意味は明確です。

反論が1点あります。

反論：`bad` という命名は「意図的な設計」であり誤解を生む名前ではない

見解では「`bad` という名前のせいで全部エラーと見えやすい」「`samples` のように分けた方が意味は明確」と言っていますが、`bad` は既存のコードで使われている命名規則に沿っており、変更する必要はありません。

既存の `bad` オブジェクトの中身を確認すると：

const bad = {
  pendingExpired: [],          // TTL切れ（グレー）
  pendingTimeoutRejected: [],  // タイムアウト通知（障害寄り）
  filedWithoutPending: [],     // 状態遷移異常（障害）
  filedTraceMismatch: [],      // traceIdズレ（障害）
  filedTcMismatch: [],         // tcScheduleズレ（障害）
  sdspFallback: [],            // フォールバック（グレー）
  sdspError: [],               // 通信エラー（障害）
  geofenceBlocked: [],         // 正規拒否（要観察）
};

最初から「障害」「グレー」「正規拒否」が混在しています。これは**「後から見返したいもの全部」を `bad` という名前で一括管理する設計**であり、`analyzeLog` の `printList` で表示するサンプル群として一貫しています。

見解が提案する `anomalies` / `rejects` / `fallbacks` への分割は概念的には整理されていますが、現状の `analyzeLog` は `bad` 全体を同じ `printList` 関数で出力しているため、分割してもコードの見やすさは変わりません。 むしろ分割することで `printList` の呼び出しが散らばり保守性が下がります。

`geofenceBlocked` が「正規拒否」であることの理解は正しいです。ただし「`bad` という名前が誤解を生む」という批判は、既存の設計意図を無視した過剰な整理提案です。

いいなと思ったら応援しよう！