待たないための2つの方法は、別のものである

2には HTTP 側に規定があります。RFC 9110(STD 97、2022年6月)§15.3.3 から逐語で。

The 202 (Accepted) status code indicates that the request has been
accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might
be disallowed when processing actually takes place.  There is no
facility in HTTP for re-sending a status code from an asynchronous
operation.
 
The 202 response is intentionally noncommittal.

読むべきは4点。

• the processing has not been completed — 処理は終わっていない
• The request might or might not eventually be acted upon — 結局実行されないこともある。 受け付けたことは、やると約束したことですらありません
• The 202 response is intentionally noncommittal — 規格自身が「意図的に何も約束していない」と言っています
• There is no facility in HTTP for re-sending a status code from an asynchronous operation — 結果が同じ応答で返らないのは、実装の手抜きではなくプロトコルにその機能が無いから

ただし同じ節は、応答が status monitor を指す(または埋め込む)表現を返すべきだ(ought to)とも書いています。結果を知る手段が無いのではなく、別途取りに行く先を示す、が正確です。

実際に測りました。同一プロセス内に3つのサーバを立て、「3秒かかる仕事」は3つとも同じ。変えたのは待ち方だけ。

• ① ランタイムが待たない(await するが JS スレッドは塞がない)
• ② 受け付けるだけ(await しない。応答と仕事が別々に進む)
• ③ 対照: ビジーループで塞いで待つ

環境は Docker Engine 28.4.0(Docker Desktop) / linux/arm64 / kernel 6.10.14-linuxkit、コンテナは node:24-alpine、Node v24.21.0 / curl 8.22.0。すべて 127.0.0.1 の自前サーバ、各1回の計測。ホストは Apple Silicon の macOS で、Docker Desktop の Linux VM 上の値です。

-- port 5001 ① ランタイムが待たない --
 HTTP/1.1 200 OK
    [status=200 time_total=3.018393s]
 body: {"id":"async-runtime","result":42}
-- port 5002 ② 受け付けるだけ --
 HTTP/1.1 202 Accepted
 location: /jobs/1
    [status=202 time_total=0.001710s]
 body: {"status":"accepted","monitor":"/jobs/1"}
-- port 5003 ③ 塞いで待つ --
 HTTP/1.1 200 OK
    [status=200 time_total=3.000238s]
 body: {"id":"blocking","result":42}

まず①と③。200 / 約3秒 / result:42。クライアントからこの2つは区別できません。 スレッドを塞ぐか待ちを預けるかは違いますが、それはサーバ側の都合で、この1本へ渡したものは同じです。

②だけが違います。0.0017 秒で 202、本文に result はなく取りに行く先だけ。ただし この桁は同一プロセス内の localhost の値で、「202 は一瞬で返る」と一般化しないでください。location: /jobs/1 は検証者が一例として付けたもので、規格が Location を要求しているわけではありません。

2026-09-18T02:48:44.331Z recv async-runtime
2026-09-18T02:48:47.339Z done async-runtime
2026-09-18T02:48:47.350Z recv accepted
2026-09-18T02:48:47.356Z recv blocking
2026-09-18T02:48:50.356Z done accepted

②が速いだけでは、仕事が軽かった場合と区別できません。決め手はサーバ側のログです。recv accepted が 47.350、done accepted が 50.356。202 を返した 3.006 秒あとに仕事が終わっています。 ②のクライアントは、仕事が終わる3秒前に「成功」を受け取って立ち去っている。①と③は逆で done async-runtime が 47.339、応答が返った時点で仕事は終わっています。