Context

A call (or any request on the Requests screen) is most useful with what it made happen on the site beside it: its dump() calls, its queries, its log lines. Dumps already say which request made them (GET /orders), but two requests to the same path at once can't be told apart that way. The link has to be exact, has to work for every request, not only Short Leash's own sends, and must not let anyone on the internet, through a share, attach their requests to someone else's.

Decision

The proxy stamps the id. Every request the proxy sends on to a site's backend (PHP-FPM, a dev server, a Python or Node app) carries X-Leash-Request: <id>, the id it's recorded under on Requests. A value the visitor sent is always replaced, so nothing from the network, a share included, can choose it. Short Leash's own sends pick the id up front, through a request extension only code inside leashd can set.
The dumps prepend reads it. For PHP, the prepend file (0011) sends the id with every dump, query, job, view, HTTP call and log line it reports, and Dumps finds them by it (Dumps::for_request). Commands, queue workers and other servers have no request, so their dumps carry none.
What it caused (GET /v1/requests/{id}/caused) returns the recorded request, its dumps by id, and the mail that arrived while it ran. Mail has no id to go by, so it's matched by time and labeled that way.

Alternatives

The client sends a trace header would only work for Short Leash's own sends, and a visitor through a share could send any value and mix their requests into someone else's.
Matching dumps by path and time works without changing anything, but mixes up concurrent requests to the same address; it's what remains for mail.

Consequences

Every site sees one more request header; an app that logs or forwards all its incoming headers will show it.
Only PHP sites get dumps tied to requests today; others show the recorded request only.
Queued jobs and mail sent from them aren't tied to the request that queued them.