linera-io/linera-protocol · error · ExecutionError

BlobsNotFound

BlobsNotFound

Error message

ExecutionError::BlobsNotFound(missing_blobs)

What it means

When an application is created, the system loads the ApplicationDescription blob and then verifies that every bytecode blob of the referenced module (contract and service bytecode for each bytecode type) is available — either published in the same transaction's created blobs or present in the node's blob storage. This error carries the list of missing BlobIds: the bytecode needed to run the application does not exist where the executor looked for it.

Source

Thrown at linera-execution/src/system.rs:1186

    async fn check_bytecode_blobs(
        &self,
        module_id: &ModuleId,
        txn_tracker: &TransactionTracker,
    ) -> Result<Vec<BlobId>, ExecutionError> {
        let blob_ids = module_id.bytecode_blob_ids();

        let mut missing_blobs = Vec::new();
        for blob_id in &blob_ids {
            // First check if blob is present in created_blobs
            if txn_tracker.created_blobs().contains_key(blob_id) {
                continue; // Blob found in created_blobs, it's ok
            }
            // If not in created_blobs, check storage
            if !self.context().extra().contains_blob(*blob_id).await? {
                missing_blobs.push(*blob_id);
            }
        }
        ensure!(
            missing_blobs.is_empty(),
            ExecutionError::BlobsNotFound(missing_blobs)
        );

        Ok(blob_ids)
    }
}

View on GitHub (pinned to 6c226ddcb3)

Solutions

  1. Publish the module bytecode first (SystemOperation::PublishModule, or linera publish-module) so the listed blob IDs exist in storage, then create the application.
  2. Recompute the ModuleId from the exact bytecode you upload — the ID hashes the contract and service bytes, so any rebuild or recompile changes it.
  3. If blobs were pruned or lost, re-upload the missing blobs identified by the BlobIds in the error payload, then retry creation.
  4. Confirm client and validators point at the same network and share blob storage.

Example fix

# before: create an app whose module blobs are unknown to this network
linera create-application $STALE_MODULE_ID --json-argument '{...}'

# after: publish the bytecode blobs first, then create from the returned module ID
linera publish-module ./target/wasm32-unknown-unknown/release/my_app.wasm
# use the freshly printed ModuleId; its bytecode blobs now exist in storage
linera create-application $NEW_MODULE_ID --json-argument '{...}'
Defensive patterns

Strategy: validation

Validate before calling

// Before CreateApplication: verify every bytecode blob of the module exists
for blob_id in module_id.bytecode_blob_ids() {
    if !storage.contains_blob(&blob_id).await? {
        return Err(anyhow!(
            "missing blob {blob_id}: publish the module first"
        ));
    }
}

Type guard

fn is_blobs_not_found(e: &ExecutionError) -> bool {
    matches!(e, ExecutionError::BlobsNotFound(_))
}

Try / catch

match result {
    Err(ExecutionError::BlobsNotFound(missing)) => {
        // `missing` lists the exact BlobIds that are absent:
        // publish/re-upload those blobs, then retry the creation.
    }
    Err(e) => return Err(e.into()),
    Ok(value) => { /* ... */ }
}

Prevention

When it happens

Trigger: Executing SystemOperation::CreateApplication whose ModuleId references bytecode blobs that were never published or not propagated to this chain/validator; a module_id computed over different bytecode bytes than what was actually uploaded; blobs removed by pruning or garbage collection; an application description copied from another network (devnet vs testnet) whose blobs were never uploaded here.

Common situations: Publishing a module on one network and creating the application against another; a stale cached module_id after recompiling the WASM (bytes change, so the content hash changes); blob pruning on long-running testnets; replaying an old CreateApplication transaction without its companion PublishModule data.

Related errors


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