fix(ipc): close uninitialized supervised process

[rosetta-livekit-bot]

Ports livekit/agents#6051 to agents-js.\n\nWhen a supervised process is closed before initialization completes, reject the initialization future to unblock the supervisor task, kill the child process directly, and wait for join cleanup instead of sending a graceful shutdown the child cannot handle yet.\n\nTests:\n- pnpm test agents/src/ipc/supervised_proc.test.ts\n- pnpm build:agents\n\nNo tests were added, matching the porting instruction.

---

Ported from livekit/agents#6051

Original PR description

Summary

test_slow_initialization flakes on CI with a leaked ProcJobExecutor._supervise_task at teardown. The root cause is a real shutdown race in SupervisedProc, not a test issue.

When the owning task (e.g. ProcPool._proc_spawn_task during pool close) is cancelled while awaiting start(), the shielded _start() keeps running and creates the supervise task afterwards. The cleanup path then calls aclose(), which no-ops because the proc isn't marked started yet — leaking the supervise task and the child process. The orphaned child blocks forever waiting for InitializeRequest, and its non-daemon join thread can hang worker shutdown indefinitely.

Changes

• start() keeps a handle on the shielded _start() task; aclose() waits for it before checking started, so an abandoned start can't race past the check.
• aclose() kills a never-initialized process instead of attempting a graceful shutdown: the child reads InitializeRequest before servicing any other message, so a ShutdownRequest could never be acked.
• kill() resolves a pending _initialize_fut so the supervise task (which waits on it before supervising) can observe the process exit.
• Added test_aclose_after_cancelled_start, which deterministically reproduces the leak (fails the leaked-tasks check and hangs pytest exit without the fix).

nit: Also sets the agent session tests to speed = 1 and raises the default drain_delay — they run under virtual time, so the speed factor no longer buys wall-clock time.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 409b1b6

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🚩 initialize() caller may hang when close() is called during initialization

The new close() path correctly rejects init and resolves #join, fixing the issue where close() itself would hang. However, if a caller (e.g. proc_pool.ts:108-109 in procWatchTask) is concurrently awaiting proc.initialize(), that call hangs forever on once(this.proc!, 'message') at supervised_proc.ts:217 because killing a child process emits 'exit'/'close' but NOT 'error', so events.once() never resolves or rejects. This is a pre-existing issue not introduced by this PR — in fact, the old code was worse because close() itself would also hang. The fix here is a meaningful improvement, but a complete solution would also need initialize() to detect the killed process (e.g., by racing once(proc, 'message') with once(proc, 'exit') or using an AbortSignal).

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Devin Review found 4 new potential issues.

[devin-ai-integration]

🟡 Provider tool additions and removals are silently ignored in update notifications, despite being tracked at startup

Provider tool IDs are omitted from the added/removed diff when tools are updated at runtime (updateTools at agents/src/voice/agent_activity.ts:786-799), even though they are included in the initial config notification at startup (agents/src/voice/agent_activity.ts:497-500), so the session history and chat context never record mid-session provider-tool changes.

Impact: The LLM's chat history shows provider tools appearing at startup but never being added or removed later, which could confuse context-aware models or break audit trails.

Mechanism: initial setup includes provider tool IDs but updateTools only diffs function tools

At startup (agents/src/voice/agent_activity.ts:497-500):

const initialTools = [
  ...Object.keys(this.agent._toolCtx.functionTools),
  ...this.agent._toolCtx.providerTools.map((t) => t.id),
];

But in updateTools (agents/src/voice/agent_activity.ts:786-799):

const oldToolNames = new Set(Object.keys(oldToolCtx.functionTools));
...
const newToolNames = new Set(Object.keys(newToolCtx.functionTools));

Only function tool names are compared. Provider tools from oldToolCtx.providerTools and newToolCtx.providerTools are never diffed, so adding or removing a ProviderTool via updateTools produces no AgentConfigUpdate entry in the chat context or session history.

Prompt for agents

In agent_activity.ts updateTools(), the toolsAdded/toolsRemoved diff only considers function tool names (Object.keys of functionTools). But the initial setup at lines 497-500 includes provider tool IDs via providerTools.map(t => t.id). To be consistent, updateTools should also diff provider tool IDs. Compute old and new provider tool ID sets alongside the function tool name sets, and include any added/removed provider tool IDs in the AgentConfigUpdate.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 Flattening llm/voice/metrics exports to the package root may cause future name collisions

The new agents/src/index.ts:23-24 does both export * from './llm/index.js' and export * as llm from './llm/index.js' (similarly for voice at lines 39-40 and metrics at lines 26-27). This means every named export from those modules is now available at the package root AND under the namespace. Today there are no collisions between llm, voice, and metrics exports, but any future addition of a symbol with the same name in two of these modules would cause a TypeScript error at the re-export site. The old approach (namespace-only exports) was collision-proof by design.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 Dynamic toolset push uses fire-and-forget async, which can interleave with concurrent pushes

When a toolset pushes new tools at runtime via the updateTools callback wired in setupToolsetList (agents/src/voice/agent_activity.ts:4220-4225), onToolsetToolsChanged is called fire-and-forget (void this.onToolsetToolsChanged().catch(...)). If two toolsets push tools concurrently, two onToolsetToolsChanged → updateTools calls can interleave, potentially producing incorrect toolsAdded/toolsRemoved diffs in the AgentConfigUpdate (the second call reads oldToolCtx before the first call has written newToolCtx). The final tool state converges correctly because each call re-flattens from the source toolsets, but transient config-update entries in the chat history could be wrong.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 ElevenLabs STT default commit strategy changed from 'vad' to 'manual'

The #connectWs method in plugins/elevenlabs/src/stt.ts:653-654 changed the default commit strategy. Previously, when serverVad was undefined (not explicitly set by the user), the condition this.#opts.serverVad === null was false, so commitStrategy defaulted to 'vad'. Now the condition serverVad === undefined || serverVad === null catches both cases, defaulting to 'manual'. This is a behavioral change for users who don't explicitly set serverVad: their ElevenLabs STT streams will now use manual commit instead of server-side VAD. The tests were updated to match, and a new END_OF_SPEECH emission was added for the server-VAD path at line 799-803.

---

Was this helpful? React with 👍 or 👎 to provide feedback.