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
- Regenerate the ABI (forc build) with the forc version pinned by the fuels release you use
- Upgrade the fuels crate to the version paired with your forc/Sway version (SDK version table)
- Validate the ABI JSON parses and that every typeId referenced by loggedTypes exists in the types array
- 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
- Always regenerate the ABI with the forc version pinned by your fuels release (fuelup default pin)
- Never hand-edit generated ABI JSON
- Commit the contract source next to its generated ABI so CI can rebuild both together
- Upgrade fuels and forc in the same change set
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
- log id should be a valid u64 string
- log id should be a valid u64 string
- abigen generation failed
- Only one `Abigen` command allowed
- Add an `Abigen(..)` command!
AI-assisted analysis of FuelLabs/fuels-rs@d9a250a518 (2026-08-16).
Data as JSON: /api/errors/a6dc4df88e05cf55.
Report an issue: GitHub.