FuelLabs/fuels-rs · error

Error while trying to fetch wallets from the custom provider

Error message

Error while trying to fetch wallets from the custom provider

What it means

setup_program_test! expands to test code that calls launch_custom_provider_and_get_wallets(WalletsConfig::new(n, ...)) when wallets are declared in the macro. The .await.expect panics when starting the local fuel-core provider or creating/funding the wallets fails, and the bare message hides the underlying error.

Source

Thrown at packages/fuels-macros/src/setup_program_test/code_gen.rs:103

    } else {
        return Default::default();
    };

    let wallet_names = extract_wallet_names(&command);

    if wallet_names.is_empty() {
        return Default::default();
    }

    let num_wallets = wallet_names.len();
    quote! {
        let [#(#wallet_names),*]: [_; #num_wallets] = ::fuels::test_helpers::launch_custom_provider_and_get_wallets(
            ::fuels::test_helpers::WalletsConfig::new(Some(#num_wallets as u64), None, None),
            None,
            None,
        )
        .await
        .expect("Error while trying to fetch wallets from the custom provider")
        .try_into()
        .expect("Should have the exact number of wallets");
    }
}

fn extract_wallet_names(command: &InitializeWalletCommand) -> Vec<Ident> {
    command
        .names
        .iter()
        .map(|name| ident(&name.value()))
        .collect()
}

fn contract_deploying_code(
    commands: &[DeployContractCommand],
    project_lookup: &HashMap<String, Project>,
) -> TokenStream {
    commands

View on GitHub (pinned to d9a250a518)

Solutions

1. Kill leftover fuel-core processes / free the port the provider binds
2. Ensure the fuel-core binary is available (cached binary or network access) and matches the expected version
3. Reduce the number of wallets requested to lower startup pressure
4. Replace the macro-generated setup with a manual launch_custom_provider_and_get_wallets call using ? so the real error surfaces

Example fix

// before (inside setup_program_test!): generated code panics with a generic message
// wallets(bob, alice),

// after: manual setup with real error propagation
#[tokio::test]
async fn my_test() -> anyhow::Result<()> {
    let wallets = fuels::test_helpers::launch_custom_provider_and_get_wallets(
        fuels::test_helpers::WalletsConfig::new(Some(2), None, None), None, None)
        .await?; // underlying error is shown instead of a bare panic
    Ok(())
}

// Fail fast when the provider port is occupied before running the macro-generated setup
let port_free = std::net::TcpListener::bind(("127.0.0.1", 0)).is_ok();
assert!(port_free, "cannot bind local port for the test provider");
// (shell) kill leftover nodes: pkill -f fuel-core || true

// Replace the macro-generated setup with manual setup and `?` so the real error surfaces
#[tokio::test]
async fn my_test() -> anyhow::Result<()> {
    let wallets = fuels::test_helpers::launch_custom_provider_and_get_wallets(
        fuels::test_helpers::WalletsConfig::new(Some(2), None, None),
        None,
        None,
    )
    .await?;
    Ok(())
}

When it happens

Trigger: Declaring wallets in setup_program_test! while the fuel-core binary required by the crate configuration cannot be fetched/executed, the provider port is already taken by a leftover process, or the local node crashes during wallet funding.

Common situations: Sandboxed CI without network to download the fuel-core binary; a previous test run left a fuel-core process holding the port; fuel-core version configured incompatibly.

Related errors

• Failed to load the contract
• Failed to deploy the contract
• HOME env var missing
• abigen generation failed

AI-assisted analysis of FuelLabs/fuels-rs@d9a250a518 (2026-08-16). Data as JSON: /api/errors/3ad38802833dc22c. Report an issue: GitHub.