refactor(core): acknowledge single-threaded runtime shutdown

[Parikalp-Bhardwaj]

Summary

Replaces the fixed 100ms delay in SingleThreadedRuntime::stop() with explicit
shutdown-completion acknowledgement from the runtime event loop.

stop() now relies on actual runtime lifecycle completion instead of an
arbitrary sleep.

Closes #<ISSUE_NUMBER>

Problem

Previously, SingleThreadedRuntime::stop() sent
InternalEvent::Shutdown and then waited for a fixed 100ms:

self.internal_tx
    .send(InternalEvent::Shutdown)
    .await?;

tokio::time::sleep(
    tokio::time::Duration::from_millis(100)
).await;

This did not guarantee that the runtime event loop had actually completed.

The event loop could:

• finish earlier than 100ms;
• still be draining events after 100ms;
• allow stop() to return without confirming lifecycle completion.

There was also a lifecycle edge case around run() and stop() starting
concurrently that needed deterministic synchronization.

Changes

• Removed the fixed 100ms delay from SingleThreadedRuntime::stop().
• Added explicit shutdown-completion signalling.
• Publish completion only after the event loop finishes its shutdown/drain path.
• Allow later stop() callers to observe already-completed shutdown state.
• Preserve safe repeated stop() calls.
• Preserve safe concurrent stop() calls.
• Handle stop() before run() without waiting indefinitely.
• Handle the run() / stop() startup race deterministically.
• Updated existing tests to join the runtime normally instead of aborting it
  after stop().

Shutdown Flow

Before:

stop()
  │
  ├── send Shutdown
  ├── sleep 100ms
  └── return

Now:

stop()
  │
  ├── request shutdown
  │
  └── wait for completion
             ▲
             │
       drain pending events
             │
       event loop exits
             │
       publish completion

Tests

Added/updated coverage for:

• shutdown completion acknowledgement;
• repeated stop() calls;
• concurrent stop() calls;
• stop() before run();
• run() / stop() startup race;
• normal runtime task completion after shutdown.

Compatibility

• No changes to the public Runtime trait.
• No new external dependencies.
• No changes to higher-level orchestration APIs.
• Existing shutdown behaviour remains compatible while becoming deterministic.

Related - #300

Greptile Summary

Replaces the runtime’s fixed shutdown delay with lifecycle-state synchronization and explicit completion acknowledgement.

• Atomically resolves the run()/stop() startup race.
• Uses a completion guard to release shutdown waiters on normal exit, errors, panic, or cancellation.
• Adds coverage for repeated and concurrent stops, pre-run shutdown, startup races, draining, and task cancellation.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
crates/autoagents-core/src/runtime/single_threaded.rs	Introduces atomic startup lifecycle coordination, watch-based shutdown acknowledgement, cancellation-safe completion signaling, and comprehensive lifecycle tests.

_{Reviews (3): Last reviewed commit: "fix(core): guard shutdown completion dur..." | Re-trigger Greptile}

Context used:

• Knowledge Base — Core Agent Runtime

[deepsource-io]

DeepSource Code Review

We reviewed changes in 6686655...558be87 on this pull request. Below is the summary for the review, and you can see the individual issues we found as inline review comments.

See full review on DeepSource ↗

PR Report Card

Overall Grade

Security   Reliability   Complexity   Hygiene

Code Review Summary

Analyzer	Status	Updated (UTC)	Details
Rust		Aug 10, 2026 8:00a.m.	Review ↗

---

Important

AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.

[codecov]

Codecov Report

❌ Patch coverage is 83.33333% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...tes/autoagents-core/src/runtime/single_threaded.rs	83.33%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!