xai-org/grok-build · error

set on the use_leader path

Error message

set on the use_leader path

What it means

On the `use_leader` path, when the leader connect fails and the code falls back to the embedded agent, it unwraps `fallback_flags` with `.expect("set on the use_leader path")`. The invariant is that the leader path sets `fallback_flags` before attempting the leader connect; panicking here means that invariant was broken.

Source

Thrown at crates/codegen/xai-grok-pager/src/app/mod.rs:963

        &cancel,
        connect_ui_timeout,
        primary_target,
        startup_failure::ConnectAttempt::First,
        &timer,
        async {
            if use_leader {
                crate::acp::connect_via_leader(&cancel, connect_flags, &raw_config).await
            } else {
                crate::acp::connect(&cancel, connect_flags).await
            }
        },
    )
    .await;
    let (connect_result, embedded_fallback, timer, connect_target) = match connect_result {
        Err(f) if use_leader && !cancel.is_cancelled() => {
            tracing::warn!(error = %f.error, "leader connect failed; falling back to embedded agent");
            timer.emit_telemetry(primary_target, f.outcome, f.timeout_secs, false);
            let flags = fallback_flags.expect("set on the use_leader path");
            let timer = xai_grok_telemetry::startup::begin(crate::acp::Owner::Client);
            let target = crate::acp::AgentKind::Embedded;
            let fallback = bounded_connect(
                &cancel,
                connect_ui_timeout,
                target,
                startup_failure::ConnectAttempt::AfterFallback(startup_failure::EarlierAttempt {
                    target: primary_target,
                    wait: primary_started.elapsed(),
                    outcome: f.outcome,
                    longest_step: f.longest_step,
                }),
                &timer,
                async { crate::acp::connect(&cancel, flags).await },
            )
            .await;
            (fallback, true, timer, target)
        }

View on GitHub (pinned to bc7f02eddd)

Solutions

1. Find where fallback_flags is assigned and ensure it's set unconditionally when use_leader is true, before the connect attempt.
2. Replace Option with an eagerly-built value so no unwrap is needed on the fallback path.
3. Add a debug_assert! right after the leader path to catch the unset invariant in tests.
4. Reproduce by forcing a leader connect failure (unreachable leader target) with use_leader enabled and verify fallback works.

Example fix

// before
let flags = fallback_flags.expect("set on the use_leader path");
// after
let flags = fallback_flags.unwrap_or_else(FallbackFlags::default_for_embedded);

// assert the invariant early, before attempting leader connect
debug_assert!(
    !use_leader || fallback_flags.is_some(),
    "fallback_flags must be set when use_leader"
);

let flags = fallback_flags
    .ok_or(FallbackError::FlagsNotInitialized)
    .map_err(|e| { tracing::error!(%e, "fallback flags missing"); e })?;

When it happens

Trigger: `use_leader` is true but the code path that populates `fallback_flags` (e.g. preparing embedded-agent connect flags) was skipped or reordered, so `Option::expect` fires on the fallback branch after a leader connect failure.

Common situations: Refactor that moved flag construction behind a condition not taken on the leader path; leader connect failing (which is itself common — bad leader address, agent down) and exposing the uninitialized flags; partial initialization due to an early return earlier in the function.

Related errors

• bridge spawn
• initialize through bridge
• just created
• a successful full-replace sample stashes its CompactOutput
• Task panicked: {}

AI-assisted analysis of xai-org/grok-build@bc7f02eddd (2026-08-31). Data as JSON: /api/errors/8ca81df3455810ef. Report an issue: GitHub.