# 17. Tolerant Deletion Policy for Task Cleanup

Date: 2026-02-14

## Status

Accepted

## Context

`spot.delete(key)` 機能は、特定のタスクに関連する「キャッシュレコード（DB）」と「実データ（Blob/File）」の両方を削除することを目的としています。

ローカルファイルシステムやS3などの外部ストレージにおいて、Blobの削除操作は様々な理由（ネットワーク障害、一時的な権限エラー、ファイルが既に手動で削除されている等）で失敗する可能性があります。

このとき、厳密な整合性を求めて「Blob削除に失敗したらDBレコードの削除もロールバック（中断）する」という実装にすると、以下のような問題が発生します：

1.  **ゾンビレコード**: 物理ファイルが見つからないだけなのに、DBからレコードを消せず、ユーザーは永遠にそのタスクを「無効化」できない。
2.  **再計算の阻害**: 破損したキャッシュエントリが残り続けることで、新しい計算結果での上書きや、クリーンな状態からの再実行が妨げられる。

## Decision

我々は、削除操作において **「メタデータの削除を優先する（Tolerant Deletion）」** ポリシーを採用します。

具体的には、`delete` メソッドの実装を以下のように規定します：

1.  まず、Blob（実データ）の削除を試みる。
2.  Blobの削除中に例外が発生した場合、**処理を中断せず**、`WARNING` レベルのログを出力してエラーを捕捉（swallow）する。
3.  Blob削除の成否に関わらず、DB上のタスクレコードの削除を必ず実行する。

## Consequences

### Positive
* **確実なリセット**: ユーザーはストレージの状態に関わらず、`beautyspot` の管理下からタスクを確実に削除できる。
* **UXの向上**: 「ファイルが見つからない」といった些細なエラーでワークフローが止まることを防げる。

### Negative
* **Orphaned Blobs（孤立ファイル）**: DBレコードは削除されたが、ストレージ上にファイルだけが残るケースが発生しうる（ストレージ容量の浪費）。
* **対策**: これらは `beautyspot` のランタイムでは管理不能となるため、必要に応じて別途ガベージコレクション（GC）ツールや、S3のライフサイクルポリシー等で対処する必要がある。

