FluxFlow.Components.RequestReply
1.0.0
See the version list below for details.
dotnet add package FluxFlow.Components.RequestReply --version 1.0.0
NuGet\Install-Package FluxFlow.Components.RequestReply -Version 1.0.0
<PackageReference Include="FluxFlow.Components.RequestReply" Version="1.0.0" />
<PackageVersion Include="FluxFlow.Components.RequestReply" Version="1.0.0" />
<PackageReference Include="FluxFlow.Components.RequestReply" />
paket add FluxFlow.Components.RequestReply --version 1.0.0
#r "nuget: FluxFlow.Components.RequestReply, 1.0.0"
#:package FluxFlow.Components.RequestReply@1.0.0
#addin nuget:?package=FluxFlow.Components.RequestReply&version=1.0.0
#tool nuget:?package=FluxFlow.Components.RequestReply&version=1.0.0
FluxFlow.Components.RequestReply
A transport-agnostic request/reply bridge for FluxFlow. HTTP is request→reply; a dataflow graph is one-way. This bridges the two and correlates the answer back to the caller — reused by the HTTP and MQTT triggers.
How it works
host adapter ──IRequestContext──▶ Incoming ─┐
│ mint/keep CorrelationId, hold in-flight
Output ◀───┘ FlowMessage<TRequest> ──▶ the graph
│
host caller ◀── context.ReplyAsync ◀── Responses ◀── FlowMessage<TResponse> ─┘ (same id)
- The host creates an
IRequestContext<TRequest, TResponse>per inbound request — it carries the request and aReplyAsync/FailAsyncthat write back to the real transport (HttpContext, an MQTT reply topic, …). The bridge never sees the transport. RequestReplyCoordinator<TRequest, TResponse>assigns aCorrelationId(or honours one the context supplies), holds the context in-flight, and emitsFlowMessage<TRequest>onOutput.- The graph maps request → response with
message.With(response), which preserves the correlation id, and posts it toResponses. - The bridge matches by id, calls
ReplyAsync, and evicts. Requests with no response withinTimeoutare failed (FailAsync) and evicted, so the map never leaks and no caller hangs forever.
Notes
Outputis a bounded buffer (reliable, backpressure) — a trigger must not drop inbound requests.Errors/Eventsare broadcast (observability).- Everything is keyed on
CorrelationIdfromFluxFlow.Nodes— the same envelope id that flows through the whole graph. - Inject a
TimeProviderfor deterministic timeout tests.
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net8.0 is compatible. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. net9.0 was computed. net9.0-android was computed. net9.0-browser was computed. net9.0-ios was computed. net9.0-maccatalyst was computed. net9.0-macos was computed. net9.0-tvos was computed. net9.0-windows was computed. net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- FluxFlow.Nodes (>= 1.0.0)
-
net8.0
- FluxFlow.Nodes (>= 1.0.0)
NuGet packages (1)
Showing the top 1 NuGet packages that depend on FluxFlow.Components.RequestReply:
| Package | Downloads |
|---|---|
|
FluxFlow.Components.Http.AspNetCore
ASP.NET Core HTTP trigger adapter for FluxFlow: maps an endpoint's HttpContext onto the request/reply bridge so an inbound request flows into a graph and the correlated response is written back. The only FluxFlow package that references ASP.NET Core. |
GitHub repositories
This package is not used by any popular GitHub repositories.
Initial request/reply bridge: RequestReplyCoordinator<TRequest, TResponse> correlates a host-supplied IRequestContext stream to a one-way graph (Output requests, Responses input) by CorrelationId, replies via the context, evicts timed-out requests, and reports on broadcast error/event ports.