[jeremydmiller]

Closes #2966.

When IMessageBus.InvokeAsync<T>(message) routes to a Wolverine.Http transport endpoint, the HTTP response body is the reply — no ReplyListener, no listener loop on the sender, no cross-loop TaskCompletionSource.

Sender

• New IInlineRequestReplyEndpoint capability (Wolverine core). MessageRoute caches endpoint as IInlineRequestReplyEndpoint once at construction (routing-compile time); when present, RemoteInvokeAsync<T> sends the request and reads the reply envelope straight back instead of registering a ReplyListener — no per-message branching, null for every other transport.
• HttpEndpoint implements the capability: serializes the request, POSTs to its OutboundUri, deserializes the reply envelope from the HTTP response body.
• IWolverineHttpTransportClient.InvokeAsync returns (status, body) so a 500 carrying an envelope-shaped error reply is read regardless of status.
• A receiver handler failure comes back as a FailureAcknowledgement reply and is rethrown as WolverineRequestReplyException — identical caller semantics to brokered request/reply.

Receiver

The existing /_wolverine/invoke endpoint already ran the handler and wrote Envelope.Response to the body. Now a handler exception maps to HTTP 500 + a FailureAcknowledgement envelope body (using IntrinsicSerializer.Write — WriteMessage intentionally throws). Outbox commit already happens (via InvokeInlineAsync's flush) before the response is written.

Design notes

• Auto-activates per endpoint via the transport capability — no user-facing opt-in flag, since the routing decision is structural.
• The brokered request/reply path is untouched (_inlineRequestReply is null for non-HTTP endpoints).
• Fire-and-forget HTTP sends (batch/inline publish) are unchanged.

Tests

inline_request_reply_sender drives the full sender path (InvokeAsync<T> → MessageRoute inline branch → HttpEndpoint → reply) with a fake transport client standing in for the receiver. The host configures no listening endpoint, so the tests only pass because the reply is read off the response slot (otherwise they'd time out):

• happy path returns the typed reply;
• a receiver-side failure surfaces as WolverineRequestReplyException.

(Pre-existing unrelated flake noted: HttpTransportExecutorTests.batch_with_multiple_queues_routes_to_correct_queue fails on clean main too.)

Verification

• New sender tests green; HTTP transport suite otherwise green.
• dotnet build wolverine.slnx -c Release clean.

Docs & follow-up

• Docs: new "Inline Request/Reply" section in guide/http/transport.md.
• Inline HTTP request/reply: full integration coverage + CritterWatch control mechanism for HTTP-only services #2989 tracks the remaining hardening — full cross-process (Kestrel) integration + compliance-suite coverage, the outbox-commit-before-response assertion, Result<T> composition (Formal support for the stupid Result pattern in "Wolverine as MediatR" usage #2221), and documenting/using this as the control mechanism for CritterWatch against HTTP-only services.

🤖 Generated with Claude Code

[jeremydmiller]

Updated per review: the sender path is now polymorphic instead of a runtime if.

• The per-call if (_inlineRequestReply != null) branch in MessageRoute.RemoteInvokeAsync<T> is gone. The "send the request and resolve the reply" step is a protected virtual sendAndAwaitReplyAsync<T> seam — the base keeps the brokered reply-tracker/listener path; a new InlineReplyMessageRoute : MessageRoute overrides it to read the reply off the transport response.
• The shape is chosen once at routing-compile time by a new MessageRoute.For(messageType, endpoint, runtime) factory (HTTP / IInlineRequestReplyEndpoint → the subclass, everything else → base). All route-construction sites now go through MessageRoute.For; it's the only place that news a route. No per-message branching anywhere.

Verified: the two inline request/reply tests pass, 41 core request/reply + routing tests pass, and dotnet build wolverine.slnx -c Release is clean.

Also filed #2994 to spec using the HTTP transport as a Wolverine cluster's node control endpoint (control queue), which builds directly on this inline request/reply work.