Function markRequestSent

Reports that the request named by id (from takeOutgoingRequests) was sent, handing back the server's raw JSON response so the machine can update its own state. An addition to the frozen surface, not a change to it -- see takeOutgoingRequests.

responseJson must be that request's own endpoint's response body, unwrapped -- see OutgoingRequest's own doc comment for the table mapping each kind to what it must contain.

Call this only for a 2xx. Send everything else to markRequestFailed. markRequestSent(id, await res.text()) without branching on the status is the obvious wrapper and it is wrong. No HTTP status crosses this boundary on this call, so a body shaped like an answer is an answer here. Reported that way, an errored keys_query tells the machine the server answered and this account has no signing identity, which is exactly the fact that authorises minting a new one over whatever the account already had.

What is rejected for you. A body is rejected with malformed_payload unless it is shaped like this endpoint's response, which means an object with no keys, or an object carrying at least one field that endpoint really returns (its row in OutgoingRequest's table). So a Matrix error (errcode), an authentication challenge (flows), a gateway's {"error":"Bad Gateway"}, an array or a proxy's HTML page, and a plain {"message":"Internal server error"} are all refused. Beyond that, keys_upload, keys_claim and room_message also reject a body missing their one required field. When a body is rejected the request named by id stays outstanding, so the same id can be retried with corrected input, and the ordinary "retry with auth merged in" flow after a 401 needs nothing special.

What that still leaves through is set out once in markRequestFailed, and it is not restated here so the two cannot drift. Branch on res.ok and call that instead of this one.

This call is what stops id being handed out again, not a courtesy notification after the fact -- see takeOutgoingRequests's own doc comment for what a product observes if it is skipped.

unknown_request does not always mean the id was never real. A keys_upload, keys_query, keys_claim or signing_keys_upload id is evicted when a later takeOutgoingRequests hands out a fresh request of the same kind, so an id held across a second drain rejects here even though this library did hand it out. The first three are re-derived on every drain; a fresh signing_keys_upload exists only after another bootstrapCrossSigning, so that one survives an ordinary second drain and not a second bootstrap. See takeOutgoingRequests for why that is deliberate and what to do instead of retrying.