104010: 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 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.