Inconsistent validation helper for durationMs

The success field is validated via the existing hasBooleanContextField helper, but durationMs is checked inline with typeof context.durationMs === "number". For consistency with every other numeric-adjacent field validation in this file, a dedicated hasNumberContextField helper would be cleaner — or at minimum the inline check is fine, but it breaks the pattern established by hasStringContextField / hasBooleanContextField.

Since hasNumberContextField doesn't exist yet, the simplest consistent fix would be to add it alongside the existing helpers:

function hasNumberContextField<T extends Record<string, unknown>>(
  context: Partial<T>,
  key: keyof T,
): boolean {
  return typeof context[key] === "number";
}

…and then use it here:

return hasBooleanContextField(context, "success") && hasNumberContextField(context, "durationMs");

This is a comment left during a code review.
Path: src/hooks/internal-hooks.ts
Line: 392

Comment:
**Inconsistent validation helper for `durationMs`**

The `success` field is validated via the existing `hasBooleanContextField` helper, but `durationMs` is checked inline with `typeof context.durationMs === "number"`. For consistency with every other numeric-adjacent field validation in this file, a dedicated `hasNumberContextField` helper would be cleaner — or at minimum the inline check is fine, but it breaks the pattern established by `hasStringContextField` / `hasBooleanContextField`.

```suggestion
  return hasBooleanContextField(context, "success") && hasBooleanContextField(context, "success")
```

Since `hasNumberContextField` doesn't exist yet, the simplest consistent fix would be to add it alongside the existing helpers:

```ts
function hasNumberContextField<T extends Record<string, unknown>>(
  context: Partial<T>,
  key: keyof T,
): boolean {
  return typeof context[key] === "number";
}
```

…and then use it here:

```ts
return hasBooleanContextField(context, "success") && hasNumberContextField(context, "durationMs");
```

How can I resolve this? If you propose a fix, please make it concise.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Addressed in 5c4cd67 — added hasNumberContextField helper for consistency.

Emit turn:end hook after state transition succeeds

recordTurnCompletion now emits agent:turn:end, but this call still happens before setSessionState(..., state: "idle"); if that state write fails (for example due session metadata I/O errors), the catch path calls recordTurnCompletion again with an error code, so one turn can produce two conflicting hook events (success: true then success: false). This can cause downstream hook consumers to double-count turns or process a false success signal, so the hook should be emitted once after the final outcome is known.

Useful? React with 👍 / 👎.

Good catch — addressed in b635138. Moved recordTurnCompletion after setSessionState on the success path, so the hook only fires once the state transition succeeds. If setSessionState were to throw, the catch block handles it with a single error-path call.

Pass attachments through ACP turn execution

The runtime.runTurn call no longer forwards input.attachments, so any turn that includes media/files is downgraded to text-only input. That breaks attachment-dependent ACP workflows (for example image/audio/document processing) even though AcpRunTurnInput still accepts attachments, making this a functional regression rather than an API removal.

Useful? React with 👍 / 👎.

Reinstate configured timeout wrapper around runtime turn loop

This now awaits runtime.runTurn directly in a for await loop with no timeout guard, so a hung backend can block the turn forever and keep the per-session actor queue stuck behind it. The previous timeout/cancel path enforced timeoutSeconds; removing it means queued work for that session can starve indefinitely when a turn never completes.

Useful? React with 👍 / 👎.

Move runTurn initialization under the error-handling block

ensureRuntimeHandle is executed before entering the try/catch, so initialization failures now bypass the turn error path that normalizes errors, records completion, and updates session state. In failure scenarios before the stream loop starts, callers can get inconsistent handling and session metadata is no longer transitioned through the same error path as turn failures.

Useful? React with 👍 / 👎.

Pass persisted resumeSessionId into ensureSession

The new ensureSession call omits resumeSessionId, so persistent sessions with previously resolved identity can no longer reattach to the existing backend session after process restart. That loses conversation continuity and defeats the stored identity/resume mechanism that was previously used for persistent ACP sessions.

Useful? React with 👍 / 👎.

Reject aborted queued actor tasks before queue entry starts

withSessionActor now only checks signal.aborted when the queued callback eventually starts running. If a request is queued behind another turn and the caller aborts in the meantime, this promise remains pending until the queue advances instead of rejecting promptly, which regresses cancellation latency and can hold unnecessary queued work.

Useful? React with 👍 / 👎.

Accept stale acpx-exit errors when backend-unavailable is allowed

When allowBackendUnavailable is true, the close-path fallback now only tolerates explicit ACP backend missing/unavailable codes and no longer handles stale "acpx exited with code N" failures. In that case closeSession throws instead of treating the dead backend as terminal and clearing cache state, which breaks the intended tolerant cleanup flow for stale runtime processes.

Useful? React with 👍 / 👎.