linera-io/linera-protocol · error · ExecutionError

BlobTooLarge

BlobTooLarge

Error message

ExecutionError::BlobTooLarge

What it means

check_blob_size enforces the committee resource policy: a blob whose content length exceeds maximum_blob_size is rejected with BlobTooLarge. The check runs wherever blobs enter execution (execute_block_inner, track_blob_published, handle_pending_blob), so oversized blob content fails the block rather than bloating storage.

Source

Thrown at linera-execution/src/policy.rs:445

    }

    pub(crate) fn fuel_price(
        &self,
        fuel: u64,
        vm_runtime: VmRuntime,
    ) -> Result<Amount, ArithmeticError> {
        self.fuel_unit_price(vm_runtime).try_mul(u128::from(fuel))
    }

    /// Returns how much fuel can be paid with the given balance.
    pub(crate) fn remaining_fuel(&self, balance: Amount, vm_runtime: VmRuntime) -> u64 {
        let fuel_unit = self.fuel_unit_price(vm_runtime);
        u64::try_from(balance.saturating_ratio(fuel_unit)).unwrap_or(u64::MAX)
    }

    /// Checks that the blob's size does not exceed the maximum allowed by this policy.
    pub fn check_blob_size(&self, content: &BlobContent) -> Result<(), ExecutionError> {
        ensure!(
            u64::try_from(content.bytes().len())
                .ok()
                .is_some_and(|size| size <= self.maximum_blob_size),
            ExecutionError::BlobTooLarge
        );
        match content.blob_type() {
            BlobType::ContractBytecode | BlobType::ServiceBytecode | BlobType::EvmBytecode => {
                ensure!(
                    CompressedBytecode::decompressed_size_at_most(
                        content.bytes(),
                        self.maximum_bytecode_size
                    )?,
                    ExecutionError::BytecodeTooLarge
                );
            }
            BlobType::Data
            | BlobType::ApplicationDescription
            | BlobType::ApplicationFormats

View on GitHub (pinned to 6c226ddcb3)

Solutions

  1. Split the content into chunks smaller than maximum_blob_size and publish multiple blobs
  2. Compress the content before publishing
  3. If you operate the network, raise maximum_blob_size in the committee resource policy (requires a new epoch)

Example fix

// before: single oversized blob
let blob = Blob::new(BlobContent::new(BlobType::Data, content)); // content.len() > policy.maximum_blob_size

// after: chunked publication under the limit
for chunk in content.chunks(maximum_blob_size as usize) {
    publish(Blob::new(BlobContent::new(BlobType::Data, chunk.to_vec())))?;
}
Defensive patterns

Strategy: validation

Validate before calling

// Validate blob size against policy before publishing
fn blob_fits_policy(content: &BlobContent, policy: &ResourceControlPolicy) -> bool {
    u64::try_from(content.bytes().len())
        .map(|size| size <= policy.maximum_blob_size)
        .unwrap_or(false)
}

if !blob_fits_policy(&content, &policy) {
    return Err(anyhow!("blob of {} bytes exceeds maximum_blob_size {}",
        content.bytes().len(), policy.maximum_blob_size));
}
publish(content)?;

Type guard

fn is_blob_too_large(err: &ExecutionError) -> bool {
    matches!(err, ExecutionError::BlobTooLarge)
}

Try / catch

match publisher.publish_blob(content).await {
    Ok(id) => id,
    Err(ref e) if is_blob_too_large(e) => {
        // deterministic: chunk or compress, then publish the pieces
        publish_in_chunks(content, policy.maximum_blob_size as usize).await
    }
    Err(e) => return Err(e.into()),
}

Prevention

When it happens

Trigger: Publishing or referencing a blob (data, bytecode, checkpoint state, etc.) whose content is larger than the current epoch's maximum_blob_size policy value.

Common situations: Uploading large datasets or generated content as a single blob; policies tightened between devnet versions; proposals bundling oversized blob content; forgetting that for non-bytecode blob types the limit applies to the raw content bytes, not a compressed size.

Related errors


AI-assisted analysis of linera-io/linera-protocol@6c226ddcb3 (2026-08-22). Data as JSON: /api/errors/3b60ebb0ba80405d. Report an issue: GitHub.