処理の失敗理由をユーザーに届ける導線を、最初に作っておく

自動取り込みが失敗しても、画面に「一部の取得に失敗しました」としか出ないと、ユーザーとの調査の往復が始まります。実際の理由が子プロセスのstderrにあるなら、必要な情報を画面まで届けます。

最終行を結果オブジェクトへ載せる

const { code, stderr } = await runChild(args);
if (code !== 0) {
  const tail = String(stderr).trim().split('\n').at(-1) ?? '';
  return { ok: false, message: `取得に失敗しました: ${redact(tail).slice(0, 200)}` };
}

missing_scopeのようなエラーコードが画面に出れば、スクリーンショット1枚で原因を絞れます。ただしトークンやpassword=...などの値は表示前にマスクします。過剰に隠してエラーコードまで消さず、秘密の値だけを除去します。

GUIでも読める失敗ログを用意する

Finderから起動したデスクトップアプリでは、console.errorをユーザーが確認できません。日時、操作種別、終了コード、マスク済みstderr末尾だけをファイルへ残します。本文や引数全体は保存しません。

失敗の経路は最初に1本へ決めます。

子プロセスのstderr
  → 結果オブジェクトのmessage
    → トースト表示
  → 機微情報を除いた失敗ログ

後付けでは子プロセスの受け口、表示コンポーネント、ログ出力先が散らばりがちです。エラーメッセージは開発時のconsoleではなく、障害時にサポートする人が原因へ到達するための機能として設計します。

今回は以上です。