t8y2/dbx · error

driver token registered

Error message

driver token registered

What it means

Before spawning per-driver installs, upgrade_all_agent_drivers_with_registry pre-registers one cancellation token per updatable driver in driver_cancellations. The .expect("driver token registered") asserts each driver being iterated has a token in that map; a missing entry means the pre-registration and the install loop got out of sync, so it panics.

Source

Thrown at crates/dbx-core/src/agent_service.rs:829

    }

    // Register a per-driver token for every driver in the batch, keyed by the
    // batch operation id so per-driver cancels target this batch's driver even
    // when the same db_type is being installed concurrently elsewhere. The
    // batch token lets one click abort the whole upgrade; each driver token
    // lets the user cancel a single driver while the rest continue.
    let mut driver_cancellations = std::collections::HashMap::new();
    for db_type in &updatable {
        let key = batch_driver_cancellation_key(effective_operation_id, db_type);
        let token = am.begin_install_cancellation(&key).await;
        driver_cancellations.insert(db_type.clone(), token);
    }

    // Run independent driver installs concurrently, with a fixed upper bound
    // so a large registry cannot saturate download and file-system resources.
    let installs = updatable.into_iter().enumerate().map(|(index, db_type)| {
        let key = batch_driver_cancellation_key(effective_operation_id, &db_type);
        let token = driver_cancellations.remove(&db_type).expect("driver token registered");
        let batch_token = Arc::clone(&active_batch_arc);
        async move {
            let result = if batch_token.is_cancelled() {
                Err(AGENT_DOWNLOAD_CANCELED_ERROR.to_string())
            } else {
                install_agent_driver_from_registry_locked(
                    am,
                    registry,
                    source,
                    &db_type,
                    progress,
                    Some((index + 1) as u32),
                    Some(total),
                    // Observe BOTH the row token (per-driver cancel) and the
                    // batch token (cancel-all): a batch cancel must interrupt a
                    // driver whose download already started, not just one that
                    // is still waiting to begin.
                    &[&token, &batch_token],

View on GitHub (pinned to c0390bff16)

Solutions

1. Register driver cancellation tokens from the exact same iterator (same snapshot) that feeds the install loop.
2. If a token is genuinely missing, fall back to creating one: driver_cancellations.entry(db_type).or_insert_with(...) or begin_install_cancellation with the per-driver key.
3. Use entry().and_expect-style removal only after asserting key presence, or restructure to carry tokens alongside drivers in one collection.
4. Add a test that every db_type in updatable has a token before the loop.

Example fix

// before
let token = driver_cancellations.remove(&db_type).expect("driver token registered");
// after
let token = match driver_cancellations.remove(&db_type) {
    Some(t) => t,
    None => am.begin_install_cancellation(&batch_driver_cancellation_key(effective_operation_id, &db_type)).await,
};

// before the install loop, verify registration coverage
for db_type in &updatable {
    assert!(driver_cancellations.contains_key(db_type), "missing token for {db_type}");
}

fn tokens_cover<'a>(tokens: &HashMap<DbType, AgentInstallCancellation>, drivers: impl IntoIterator<Item = &'a DbType>) -> bool {
    drivers.into_iter().all(|d| tokens.contains_key(d))
}

let token = match driver_cancellations.remove(&db_type) {
    Some(t) => t,
    None => return Err(format!("internal error: no cancellation token registered for {db_type}")),
};

When it happens

Trigger: The set of drivers enumerated in the install loop (updatable.into_iter()) differs from the set for which driver_cancellations was populated earlier in the same function — e.g. tokens registered before a filter/re-check of updatable drivers, or remove() called twice for the same db_type across a retry within the same run.

Common situations: Concurrent modification of the updatable list between token registration and the install map; a code change inserts or reorders filtering after token registration; batch tests exercise a path where the registration loop was skipped.

Related errors

• a batch cancellation token is always available
• a cancellation token is always available
• checked one driver
• checked one native platform
• root count checked above

AI-assisted analysis of t8y2/dbx@c0390bff16 (2026-09-05). Data as JSON: /api/errors/4fbc6ecc798c2e1c. Report an issue: GitHub.