# バッチ設計書 5-Internal::RemoveStaleContactInboxesJob

## 概要

本ドキュメントは、Chatwootアプリケーションにおける`Internal::RemoveStaleContactInboxesJob`バッチの設計仕様を記載したものである。

### 本バッチの処理概要

このバッチは、会話のない古いコンタクトインボックス（3ヶ月以上経過）を削除するハウスキーピングジョブである。

**業務上の目的・背景**：Chatwootでは、コンタクトがインボックスにアクセスするたびにコンタクトインボックスレコードが作成される。しかし、会話に至らないコンタクトインボックスは不要なデータとしてデータベースに蓄積され、パフォーマンスとストレージに悪影響を与える。このバッチは、3ヶ月以上経過しても会話が発生していないコンタクトインボックスを定期的に削除することで、データベースの健全性を維持する。

**バッチの実行タイミング**：日次で22:30 UTCに実行される。これはトラフィックが最も少ない時間帯として選択されている。

**主要な処理内容**：
1. 環境変数`REMOVE_STALE_CONTACT_INBOX_JOB_STATUS`による実行可否判定
2. 3ヶ月（90日）以上前に作成され、会話のないコンタクトインボックスを特定
3. バッチサイズ10,000件でトランザクション内で削除
4. 削除件数とSQLクエリをログ出力

**前後の処理との関連**：独立したハウスキーピングジョブとして動作。他のジョブとの依存関係はない。

**影響範囲**：contact_inboxesテーブルのレコード削除

## バッチ種別

データクリーンアップ / ハウスキーピング

## 実行スケジュール

| 項目 | 内容 |
|-----|------|
| 実行頻度 | 日次 |
| 実行時刻 | 22:30 UTC |
| 実行曜日 | 毎日 |
| 実行日 | - |
| トリガー | cron（sidekiq-cron） |

## 実行条件

### 前提条件

| 条件 | 説明 |
|-----|------|
| 環境変数設定 | `REMOVE_STALE_CONTACT_INBOX_JOB_STATUS`がtrueに設定されていること |

### 実行可否判定

環境変数`REMOVE_STALE_CONTACT_INBOX_JOB_STATUS`が設定され、その値がtrue（ActiveModel::Type::Booleanでキャスト）の場合のみ実行される。設定がない場合やfalseの場合はスキップ。

## 入力仕様

### 入力パラメータ

| パラメータ名 | 型 | 必須 | デフォルト値 | 説明 |
|-------------|-----|-----|-------------|------|
| なし | - | - | - | 本バッチは引数を取らない |

### 入力データソース

| データソース | 形式 | 説明 |
|-------------|------|------|
| contact_inboxes | DB | 削除対象のコンタクトインボックス |
| conversations | DB | 会話の有無確認（LEFT JOIN） |

## 出力仕様

### 出力データ

| 出力先 | 形式 | 説明 |
|-------|------|------|
| contact_inboxes | DB | 対象レコードの削除 |
| ログ | テキスト | 削除件数、SQLクエリの出力 |

### 出力ファイル仕様

ファイル出力なし

## 処理フロー

### 処理シーケンス

```
1. 実行可否判定
   └─ REMOVE_STALE_CONTACT_INBOX_JOB_STATUS環境変数をチェック
   └─ false/未設定の場合return
2. 削除対象の特定
   └─ stale_without_conversations(90.days.ago)スコープを使用
   └─ contact_inboxes LEFT JOIN conversationsで会話なしを判定
   └─ created_atが90日以上前のものを対象
3. ログ出力
   └─ 削除予定件数を出力
   └─ 実行SQLクエリを出力
4. バッチ削除
   └─ トランザクション開始
   └─ find_in_batches(batch_size: 10,000)で分割
   └─ delete_allでDBレベル削除
   └─ トランザクションコミット
```

### フローチャート

```mermaid
flowchart TD
    A[バッチ開始] --> B{環境変数チェック}
    B -->|false/未設定| C[処理終了]
    B -->|true| D[削除対象コンタクトインボックス検索]
    D --> E[削除件数・SQLをログ出力]
    E --> F[トランザクション開始]
    F --> G[10,000件ずつバッチ削除]
    G --> H{次のバッチあり?}
    H -->|Yes| G
    H -->|No| I[トランザクションコミット]
    I --> J[バッチ終了]
```

## データベース操作仕様

### 操作別データベース影響一覧

| 処理 | 対象テーブル | 操作種別 | 概要 |
|-----|-------------|---------|------|
| 削除対象検索 | contact_inboxes, conversations | SELECT (LEFT JOIN) | 会話なしの古いコンタクトインボックス検索 |
| レコード削除 | contact_inboxes | DELETE | 対象レコードの削除 |

### テーブル別操作詳細

#### contact_inboxes

| 操作 | 項目（カラム名） | 更新値・取得条件 | 備考 |
|-----|-----------------|-----------------|------|
| SELECT | id, created_at | created_at < 90.days.ago AND conversations.contact_id IS NULL | LEFT JOIN conversations |
| DELETE | id | 検索結果のIDリスト | delete_allで一括削除 |

## エラー処理

### エラーケース一覧

| エラーコード | エラー種別 | 発生条件 | 対処方法 |
|------------|----------|---------|---------|
| - | ActiveRecord::StatementInvalid | DB接続エラー、デッドロック等 | トランザクションロールバック、リトライ |
| - | StandardError | 予期しないエラー | Sidekiqリトライ機構に委譲 |

### リトライ仕様

| 項目 | 内容 |
|-----|------|
| リトライ回数 | Sidekiqのデフォルト設定に依存 |
| リトライ間隔 | Sidekiqのデフォルト設定に依存 |
| リトライ対象エラー | ジョブ実行時の例外全般 |

### 障害時対応

トランザクション内で処理されるため、エラー発生時は自動的にロールバックされる。翌日の定期実行で再度処理される。

## トランザクション仕様

| 項目 | 内容 |
|-----|------|
| トランザクション範囲 | 削除処理全体 |
| コミットタイミング | 全バッチ削除完了後 |
| ロールバック条件 | トランザクション内での例外発生時 |

## パフォーマンス要件

| 項目 | 内容 |
|-----|------|
| 想定処理件数 | 数千〜数百万件（環境依存） |
| 目標処理時間 | トラフィック低時間帯に完了 |
| メモリ使用量上限 | 最小限（find_in_batchesで分割処理） |

## 排他制御

同時実行の制御は特になし。日次1回のみの実行であり、通常は競合しない。トランザクション内での削除により、一貫性は保証される。

## ログ出力

| ログ種別 | 出力タイミング | 出力内容 |
|---------|--------------|---------|
| 情報ログ | 削除前 | `Deleting {count} stale contact inboxes older than {time_period}` |
| 情報ログ | 削除前 | `SQL Query: {sql}` |

## 監視・アラート

| 監視項目 | 閾値 | アラート先 |
|---------|-----|----------|
| ジョブ失敗 | 連続失敗 | Sidekiq監視 |
| 削除件数 | 異常に多い場合 | 運用監視（任意） |

## 備考

- 環境変数`REMOVE_STALE_CONTACT_INBOX_JOB_STATUS`で実行を制御できる（デフォルトは無効）
- `delete_all`を使用しているため、ActiveRecordコールバックは実行されない
- batch_size: 10,000で分割処理することで、メモリ効率とデッドロック回避を両立
- 削除対象の判定はLEFT JOINによる会話なし判定（conversations.contact_id IS NULL）
- 22:30 UTCはトラフィック最小時間帯として選択されている
