FuelLabs/fuels-rs · error

Failed to resolve log type

Error message

Failed to resolve log type

What it means

During abigen! code generation the SDK iterates the ABI's loggedTypes and resolves each type application with TypeResolver to build the Rust log-decoder bindings. This expect fires when a logged type in the ABI JSON cannot be resolved to a Rust type, meaning the type declaration graph (typeDecl plus its components) contains a shape the resolver does not understand or a reference it cannot follow.

Source

Thrown at packages/fuels-code-gen/src/program_bindings/abigen/logs.rs:29

    let resolved_logs = resolve_logs(logged_types);
    let log_id_log_formatter_pairs = generate_log_id_log_formatter_pairs(&resolved_logs);
    quote! {::fuels::core::codec::log_formatters_lookup(vec![#(#log_id_log_formatter_pairs),*], #contract_id)}
}

#[derive(Debug)]
struct ResolvedLog {
    log_id: String,
    log_formatter: TokenStream,
}

/// Reads the parsed logged types from the ABI and creates ResolvedLogs
fn resolve_logs(logged_types: &[FullLoggedType]) -> Vec<ResolvedLog> {
    logged_types
        .iter()
        .map(|l| {
            let resolved_type = TypeResolver::default()
                .resolve(&l.application)
                .expect("Failed to resolve log type");

            let is_error_type = l
                .application
                .type_decl
                .components
                .iter()
                .any(|component| component.error_message.is_some());

            let log_formatter = if is_error_type {
                quote! {
                    ::fuels::core::codec::LogFormatter::new_error::<#resolved_type>()
                }
            } else {
                quote! {
                    ::fuels::core::codec::LogFormatter::new_log::<#resolved_type>()
                }
            };

View on GitHub (pinned to d9a250a518)

Solutions

  1. Regenerate the ABI (forc build) with the forc version pinned by the fuels release you use
  2. Upgrade the fuels crate to the version paired with your forc/Sway version (SDK version table)
  3. Validate the ABI JSON parses and that every typeId referenced by loggedTypes exists in the types array
  4. If the logged type is exotic, simplify it in the Sway contract (replace complex generics/nested enums) and rebuild

Example fix

# before: ABI produced by whatever forc is on PATH
forc build

# after: pin the forc version paired with your fuels crate, then rebuild
fuelup use <forc matching your fuels release>
forc build --release
# re-run cargo build so abigen! resolves every logged type
Defensive patterns

Strategy: validation

Validate before calling

# (shell) validate the ABI before compiling the crate that runs abigen!
jq empty out/release/contract-abi.json || echo 'invalid ABI JSON'
# every loggedType must reference a declared type:
jq -e '[.loggedTypes[]?.application.typeDecl.typeId] - [.types[].typeId] | length == 0' out/release/contract-abi.json

Prevention

When it happens

Trigger: Running abigen! with an ABI generated by a forc/Sway version newer than the SDK supports (new type constructs), a hand-edited or corrupted ABI JSON, or a logged type whose application references a typeId missing from the ABI's types array.

Common situations: Upgrading forc without upgrading fuels; copying an ABI from a project built with a different toolchain; manually editing or truncating the ABI JSON.

Related errors


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