compression database height({compression_db_height}) is less

Error message

compression database height({compression_db_height}) is less than target height({target_block_height})

What it means

The compression database variant of the height guard in rollback_to: its height is Optional (None is fine), but a recorded height below target_block_height aborts the rollback because the compression DB cannot be advanced by a rollback. This keeps compressed-state history consistent with the chain height being rolled back to.

Source

Thrown at crates/fuel-core/src/combined_database.rs:549

                return Err(anyhow::anyhow!(
                    "off-chain database height({off_chain_height}) \
                    is less than target height({target_block_height})"
                ));
            }

            if let Some(gas_price_chain_height) = gas_price_chain_height
                && gas_price_chain_height < target_block_height
            {
                return Err(anyhow::anyhow!(
                    "gas-price database height({gas_price_chain_height}) \
                    is less than target height({target_block_height})"
                ));
            }

            if let Some(compression_db_height) = compression_db_height
                && compression_db_height < target_block_height
            {
                return Err(anyhow::anyhow!(
                    "compression database height({compression_db_height}) \
                    is less than target height({target_block_height})"
                ));
            }

            if on_chain_height > target_block_height {
                self.on_chain().rollback_last_block()?;
            }

            if off_chain_height > target_block_height {
                self.off_chain().rollback_last_block()?;
            }

            if let Some(gas_price_chain_height) = gas_price_chain_height
                && gas_price_chain_height > target_block_height
            {
                self.gas_price().rollback_last_block()?;
            }

View on GitHub (pinned to b9d4d170da)

Solutions

Run the node until the compression DB records heights up to the chain height, then retry the rollback.
Pick a target_block_height no greater than the compression DB height if that history must be kept.
If compression history is rebuildable, clear the compression database and let it re-initialize (height None is permitted).

Defensive patterns

Strategy: validation

Validate before calling

if let Some(comp_height) = combined_db.compression().latest_height_from_metadata()? {
    if target_block_height > comp_height {
        anyhow::bail!("target {} above compression DB height {}", target_block_height, comp_height);
    }
}

Try / catch

match combined_db.rollback_to(target, &mut shutdown) {
    Ok(()) => Ok(()),
    Err(e) if e.to_string().contains("compression database height") => {
        // let compression writer catch up, or cap the target at its height
        let cap = combined_db.compression().latest_height_from_metadata()?.unwrap_or(target);
        combined_db.rollback_to(target.min(cap), &mut shutdown)
    }
    Err(e) => Err(e),
}

Prevention

Don't toggle the compression feature on an existing chain mid-height without re-baselining its DB.
Watch compression writer errors: silent failures leave its height stale.
Compression height is Optional — prefer wiping and rebuilding over rolling back a lagging DB.

When it happens

Trigger: rollback_to with target_block_height above the compression database's recorded height — compression registry/state stopped being written before the target, or the compression DB was restored from an older snapshot than the rest.

Common situations: Compression feature enabled mid-chain or disabled for a period; partial snapshot restore omitting newer compression data; compression writer failures going unnoticed while the chain advanced.

Related errors

AI-assisted analysis of FuelLabs/fuel-core@b9d4d170da (2026-08-16). Data as JSON: /api/errors/978aadf510e37df7. Report an issue: GitHub.