# 104010: Adopted run start not observed

Identifier: `adopted_run_start_not_observed`



A fresh process adopting an AI Transport run waited for that run's start event to appear on the channel, but the wait timed out before it was seen.

## What you should do

Retry the adoption a bounded number of times. A retry only helps in the narrow case where the run had started but its run-start had not yet reached the channel when the adopting process looked. More often a persistent timeout means no run with that `runId` exists on the channel at all: the id is wrong or stale, carried over from another session, or its run-start was never published because the process that started it did not get that far. Retrying cannot fix any of those. So treat a repeated timeout as a missing run and verify the `runId` belongs to this channel and that its run was actually started, rather than waiting on a run that will never appear. If a history fetch failed during the wait, it is preserved as the `cause`.

## Why it happens

Adopting a run lets a fresh process take over an already-started run by its `runId` and continue it without re-publishing its run-start, the pattern [durable execution](https://ably.com/docs/ai-transport/features/durable-execution.md) uses to span a run across processes. Before it can publish, the adopting process must observe that run's `ai-run-start` on the channel; the SDK looks for it on both the live subscription and a bounded scan of channel history. This error is raised when neither surfaces it within the timeout, because the run-start has not yet been published or the history scan was exhausted first. A history-fetch failure during the wait is preserved as the `cause`.

## What you'll see

The error is reported with code 104010 and status 504. The message names the run and the timeout, in the form `unable to load run; run-start for run ... not observed within ...ms`.