トランザクションの結果
rippledサーバは、トランザクション結果の要約を結果コードで示し、結果コードはengine_resultやmeta.TransactionResultなどのフィールドに記述されます。これらのコードは、それぞれ異なるプレフィクスを付加した複数のカテゴリに分類されます。
| カテゴリ | プレフィクス | 説明 |
|---|---|---|
| コストの請求のみ | tec | トランザクションは意図された目的を果さず、トランザクションコストは消却されました。この結果が最終的なものになるのは、検証済みレジャーに記録された場合のみです。 |
| 失敗 | tef | サーバの現在の（進行中の）レジャーまたはその後のレジャーに対して、トランザクションを適用できません。すでに適用されているか、レジャーの状態が原因となって、将来の適用が不可能になっています。 |
| ローカルエラー | tel | 負荷が高いなど、ローカルの状態が原因となって、rippledサーバでエラーが発生しました。サーバまたは時間を変えて再送信すると、別のレスポンスを得られる可能性があります。 |
| 形式が正しくないトランザクション | tem | 構文が誤っている、オプションが互いに矛盾している、署名が不正であるなどの原因で、トランザクションが無効になっています。 |
| 再試行 | ter | トランザクションを適用できませんでしたが、後ほど適用できる可能性があります。 |
| 成功 | tes | （エラーではありません）トランザクションは成功しました。この結果が最終的なものになるのは、検証済みレジャーに記録された場合のみです。 |
ローカルエラー（tel）と形式が正しくないトランザクション（tem）の違いは、プロトコルレベルでのルールの問題です。例えば、トランザクションに含めることができるパスの最大数について、プロトコルでは上限が設定されていないとします。一方、サーバでは、処理できるパスの数について上限を定義している場合があります。2つのサーバがあり、設定がそれぞれ異なっている場合、一方はパスが多いという理由でトランザクションのtelエラーを返すのに対して、他方のサーバではトランザクションが正常に処理されることもあります。コンセンサスを獲得したトランザクションを処理できるサーバが十分にある場合、検証済みレジャーに含まれる可能性はあります。
これに対して、temエラーは、設定にかかわらずトランザクションを適用できるサーバが存在しないことを示唆しています。トランザクションがプロトコルのルールに違反しているか、許容限度を超えてあいまいであるか、完全に無意味なものになっています。形式が正しくないトランザクションが有効なものになる可能性があるのは、プロトコルに変更が生じた場合のみです。例えば、新しい機能が採用された場合、当該の機能を使用するトランザクションは、当該の機能がまだ採用されていない古いソフトウェアを実行しているサーバによって、形式が正しくないと見なされる可能性があります。
即時のレスポンス
submitメソッドから返されるレスポンスには、トランザクションのローカル処理中に発生した事項を示す、rippledサーバからの暫定的な結果が含まれています。
submitからのレスポンスに含まれているのは、以下のフィールドです。
| フィールド | 値 | 説明 |
|---|---|---|
engine_result | 文字列 | 結果を分類するコード。例: tecPATH_DRY |
engine_result_code | 符号付き整数 | engine_resultに対応する数値。値そのものは変更される可能性があります。 |
engine_result_message | 文字列 | 発生した事項を説明する、人間が読める形式のメッセージ。このメッセージは、問題を診断する目的で開発者に利用されることを想定したものであり、通知なく変更される可能性があります。 |
トランザクションをローカルで送信して適用した時点で問題がない場合、レスポンスは以下のような内容になります。
"engine_result": "tesSUCCESS",
"engine_result_code": 0,
"engine_result_message": "The transaction was applied.Only final in a validated ledger."