Remove five-second shutdown delay when progress is disabled

[thomhurst]

When console progress is disabled, ConsoleCoordinator creates a no-op session but still waits indefinitely for cancellation. PrintProgressExecutor cancels that wait only after its five-second shutdown grace period, adding five seconds to every pipeline run. Tests that repeatedly run pipelines compound this delay, contributing to the roughly 20-minute core test run.

Return immediately after creating a no-op progress session. Real progress sessions retain their existing lifecycle. Add a regression test that verifies disabled progress completes without cancellation while still disabling output deferral.

Validation:

• Confirmed the regression test fails before the fix and passes afterward.
• Representative three-run cache test with coverage: 16.73 seconds before, 1.66 seconds after.
• Full core test project on Windows with coverage and eight concurrent tests: 2,672 passed, 2 skipped in 4m 13s.
• Targeted project build and git diff --check passed.

The local timing is not a like-for-like CI comparison; a fresh CI run will establish the new Linux duration.

Summary by CodeRabbit

• Bug Fixes

  • Progress operations now complete promptly when progress output is disabled, instead of waiting unnecessarily for cancellation.
  • Active progress sessions continue to follow their existing cancellation behavior.

• Tests

  • Added coverage confirming disabled progress completes successfully without delay.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 7a9a185f-d63f-4bb4-a37b-eafe46b80a14

📥 Commits

Reviewing files that changed from the base of the PR and between 3d3f831 and 3d2e4ed.

📒 Files selected for processing (2)

• src/ModularPipelines/Console/ConsoleCoordinator.cs
• test/ModularPipelines.UnitTests/Console/ConsoleCoordinatorTests.cs

Included review availability: Your plan provides up to 4 included reviews per hour; 2 remain after this review.

---

📝 Walkthrough

Walkthrough

RunAsync now completes immediately when progress output is disabled. A unit test verifies completion without cancellation waiting and confirms progress deactivation.

Changes

Progress completion

Layer / File(s)	Summary
Disabled progress completion src/ModularPipelines/Console/ConsoleCoordinator.cs, test/ModularPipelines.UnitTests/Console/ConsoleCoordinatorTests.cs	RunAsync returns immediately for NoOpProgressSession. The test verifies task completion and one SetProgressActive(false) call.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 3d2e4

Disabled console progress now finishes immediately instead of waiting for cancellation, while enabled progress behavior remains unchanged. The behavior is covered by a regression test, with no current merge-blocking risk identified.

Poem

A rabbit found a progress screen
That stayed quiet, blank, and clean
No waiting loop could make it hop
The task now finishes with a stop
One test checks the signal true
And carrots celebrate the queue

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: removing the five-second shutdown delay when progress output is disabled.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/disabled-progress-shutdown-delay

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Review: Remove five-second shutdown delay when progress is disabled

Root cause and fix are well-diagnosed. PrintProgressExecutor.DisposeAsync calls CancelAfter(5000) and then awaits the progress task; when ShowProgress is false, ConsoleCoordinator.RunAsync was still parked on Task.Delay(Timeout.Infinite, cancellationToken) after creating the NoOpProgressSession, so every pipeline run paid the full 5s grace period for a display that does nothing. The fix (src/ModularPipelines/Console/ConsoleCoordinator.cs) adds an early return right after session is NoOpProgressSession, which lets _printProgressTask complete immediately and short-circuits the wait in DisposeAsync.

Traced through the surrounding code to confirm no regression:

• BeginProgressAsync already calls _outputCoordinator.SetProgressActive(false) before returning the no-op session, so output-buffering behavior is unchanged — the new early return doesn't skip anything load-bearing.
• await using still runs NoOpProgressSession.DisposeAsync() (a no-op) on the early-return path, so disposal semantics are preserved.
• The real ProgressSession path is untouched, so the existing lifecycle for progress-enabled runs is unaffected.

Test coverage is appropriate. DisabledProgress_CompletesWithoutWaitingForCancellation asserts progress.IsCompletedSuccessfully synchronously (proving no wait occurred) and verifies SetProgressActive(false) was still invoked, which is exactly the two behaviors this fix needs to preserve/change. Naming and structure match the existing tests in this file.

No actionable issues found — this is a tightly scoped, correctly targeted fix with a regression test that would have caught the bug.