n8nでdosyaノードの失敗に対処

項目を再実行する前に、ノードのエラーメッセージと説明の両方を読んでください。通信処理は可能な限りdosyaの分かりやすい拒否メッセージを保持し、対処のヒントを追加します。自動再試行は繰り返しても安全なリクエストに限定されます。

手順

1. 失敗した実行を開き、ノード名、項目のインデックス、HTTPコード、メッセージ、説明、実行時刻を記録してください。診断情報を共有する前にAPIキーと公開URLを伏せてください。
2. dosya.dev did not accept the API key（401）の場合は、誤って入力したキー、期限切れのキー、取り消されたキーを交換してください。同じ認証情報で再実行しても復旧しません。
3. 403の場合は、拒否の内容に応じて対処してください。書き込みにはフルアクセスが必要です。フォルダーに固定されたキーはRESTを使用できません。メンバーの権限とワークスペースへの固定も適用されます。
4. 404の場合は、割り当てたIDと、対象がゴミ箱に移動されたかキーから見えなくなったかを確認してください。413の場合は、ファイルをプラン、ワークスペース、キーのファイルごとの上限と照らし合わせてください。
5. 429の場合は、表示されたRetry-Afterに従ってください。ノードは最大3回試行し、待機時間が30秒以下の場合のみ待機します。それより長い待機時間は、Waitノードまたは後の実行で使えるよう報告されます。
6. 再実行するかどうか判断してください。冪等な読み取り、フォルダー作成、および冪等性キーを持つアップロードリクエストは、一時的な通信エラーと502/503/504の後に再試行できます。共有リンクの作成は、これらのエラーの後に再試行できません。

Continue On Failを有効にすると、失敗した各入力は対応する入力のインデックスとともに{ "error": "…" }の形式の項目になり、後続の入力項目の処理が続きます。無効の場合、ノードはエラーを発生させて停止します。後の項目が失敗しても、それ以前に成功した項目はロールバックされません。

実行結果

修正後の実行は完了するか、失敗した入力ごとに意図したエラー項目を出力します。再試行回数には上限があり、サーバーから指定された長い待機時間が守られます。すでに完了している可能性のある非冪等な操作は、次のリクエストの前に確認されます。

非冪等なステップでのCould not reach dosya.devは、処理結果がすでに存在する可能性を明示的に警告します。**You’ve used …**で始まるストレージのメッセージには、プランのストレージを空けるかアップグレードして対処してください。ワークスペースのストレージ上限に関するメッセージの場合は、管理者が別途その上限を引き上げる必要があります。

関連ガイド

• dosyaをn8nに接続する
• n8nワークフローを作成する