Summary: DataflowPipeline.Execute(string) calls InputtersFlow.ProcessAsync(new[] { input }) — the single-arg Dataflow<TIn>.ProcessAsync(IEnumerable<TIn>) overload that posts items but does NOT signal completeFlowOnFinish: true, then awaits OutputtersFlow.CompletionTask. With finite input on a terminal pipeline (nothing downstream keeps the inputters flow open), upstream completion never signals → the outputter's CompletionTask blocks forever. This is the same Gridsum.DataflowEx completion-semantics pattern that prevents Shell.Run from being driven end-to-end in the unit suite today.
Where
Sources/Libraries/ProjectV.DataPipeline/DataflowPipeline.cs — Execute(string).
Suggested fix
Switch the call to the two-arg overload: InputtersFlow.ProcessAsync(new[] { input }, completeFlowOnFinish: true). The integration test already drives the production wiring with that overload and completes in ~90 ms; the production change is the same one-line swap.
Verification today (test-side workaround)
Sources/Tests/ProjectV.DataPipeline.Tests/DataflowPipelineTests.cs reproduces Execute's logical contract by driving sut.InputtersFlow.ProcessAsync(new[] { input }, completeFlowOnFinish: true) directly. The pipeline plumbing under test (4 real stages wired in the production order, with NSubstitute leaves) is identical to what Execute exercises in production. An extensive <remarks> block on that test documents the deviation.
Acceptance
- Production
Execute(string) completes on a terminal pipeline without test-side workaround.
- The existing integration test in
ProjectV.DataPipeline.Tests flips to drive Execute(...) directly instead of InputtersFlow.ProcessAsync(..., completeFlowOnFinish: true) and still completes within the suite's 30-second xUnit timeout.
Shell.Run end-to-end test (currently "tested around" in ProjectV.Core.Tests) becomes drivable.
Surfaced by
Phase 2 Test Coverage (milestone v0.9.8) — Test (Integration) stage on ProjectV.DataPipeline.Tests. Companion to the predicated-link deadlock in InputtersFlow (separate issue) — both are Gridsum-completion-semantics latent bugs surfaced together by the Phase 2 test build-out.
Summary:
DataflowPipeline.Execute(string)callsInputtersFlow.ProcessAsync(new[] { input })— the single-argDataflow<TIn>.ProcessAsync(IEnumerable<TIn>)overload that posts items but does NOT signalcompleteFlowOnFinish: true, then awaitsOutputtersFlow.CompletionTask. With finite input on a terminal pipeline (nothing downstream keeps the inputters flow open), upstream completion never signals → the outputter'sCompletionTaskblocks forever. This is the same Gridsum.DataflowEx completion-semantics pattern that preventsShell.Runfrom being driven end-to-end in the unit suite today.Where
Sources/Libraries/ProjectV.DataPipeline/DataflowPipeline.cs—Execute(string).Suggested fix
Switch the call to the two-arg overload:
InputtersFlow.ProcessAsync(new[] { input }, completeFlowOnFinish: true). The integration test already drives the production wiring with that overload and completes in ~90 ms; the production change is the same one-line swap.Verification today (test-side workaround)
Sources/Tests/ProjectV.DataPipeline.Tests/DataflowPipelineTests.csreproducesExecute's logical contract by drivingsut.InputtersFlow.ProcessAsync(new[] { input }, completeFlowOnFinish: true)directly. The pipeline plumbing under test (4 real stages wired in the production order, with NSubstitute leaves) is identical to whatExecuteexercises in production. An extensive<remarks>block on that test documents the deviation.Acceptance
Execute(string)completes on a terminal pipeline without test-side workaround.ProjectV.DataPipeline.Testsflips to driveExecute(...)directly instead ofInputtersFlow.ProcessAsync(..., completeFlowOnFinish: true)and still completes within the suite's 30-second xUnit timeout.Shell.Runend-to-end test (currently "tested around" inProjectV.Core.Tests) becomes drivable.Surfaced by
Phase 2 Test Coverage (milestone v0.9.8) —
Test (Integration)stage onProjectV.DataPipeline.Tests. Companion to the predicated-link deadlock inInputtersFlow(separate issue) — both are Gridsum-completion-semantics latent bugs surfaced together by the Phase 2 test build-out.