hyperledger/fabric · critical

commit failed

Error message

commit failed

What it means

StoreBlock wraps any error returned by the ledger's CommitLegacy with errors.Wrap(err, "commit failed"). The wrapped cause is the actual ledger error (e.g. duplicate commit, state DB failure), and this message indicates the block and its private data could not be persisted to the ledger.

Source

Thrown at gossip/privdata/coordinator.go:231

	}

	// Retrieve the private data.
	// RetrievePvtdata checks this peer's eligibility and then retreives from cache, transient store, or from a remote peer.
	retrievedPvtdata, err := pdp.RetrievePvtdata(pvtdataToRetrieve)
	if err != nil {
		c.logger.Warningf("Failed to retrieve pvtdata: %s", err)
		return err
	}

	blockAndPvtData.PvtData = retrievedPvtdata.blockPvtdata.PvtData
	blockAndPvtData.MissingPvtData = retrievedPvtdata.blockPvtdata.MissingPvtData

	// commit block and private data
	commitStart := time.Now()
	err = c.CommitLegacy(blockAndPvtData, &ledger.CommitOptions{})
	c.reportCommitDuration(time.Since(commitStart))
	if err != nil {
		return errors.Wrap(err, "commit failed")
	}

	// Purge transactions
	go retrievedPvtdata.Purge()

	return nil
}

// StorePvtData used to persist private data into transient store
func (c *coordinator) StorePvtData(txID string, privData *protostransientstore.TxPvtReadWriteSetWithConfigInfo, blkHeight uint64) error {
	return c.store.Persist(txID, blkHeight, privData)
}

// GetPvtDataAndBlockByNum gets block by number and also returns all related private data
// that requesting peer is eligible for.
// The order of private data in slice of PvtDataCollections doesn't imply the order of
// transactions in the block related to these private data, to get the correct placement
// need to read TxPvtData.SeqInBlock field

View on GitHub (pinned to 2736b63f8f)

Solutions

  1. Unwrap the error (errors.Cause / %v chain) to see the ledger's root cause and address it directly
  2. Check whether the block number was already committed — if so, treat as idempotent success and skip
  3. Verify ledger/state DB health (disk space, locks, corruption) and repair or resync from genesis
  4. Rejoin the peer to the channel / rebuild the ledger if the ledger state is inconsistent

Example fix

// before
if err := c.StoreBlock(block, pvtData); err != nil {
    return err // opaque "commit failed"
}
// after
if err := c.StoreBlock(block, pvtData); err != nil {
    if strings.Contains(err.Error(), "already committed") {
        return nil // idempotent
    }
    logger.Errorf("commit failed: %+v", err) // log full cause chain
    return err
}
Defensive patterns

Strategy: try-catch

Validate before calling

// pre-check: avoid duplicate commit
current, _ := ledger.GetBlockchainInfo()
if block.Header.Number <= current.Height-1 {
    return nil // already committed
}

Try / catch

err := coordinator.StoreBlock(block, pvtData)
if err != nil {
    var root error = err
    for errors.Unwrap(root) != nil { root = errors.Unwrap(root) }
    logger.Errorf("commit failed, root cause: %v", root)
    if isAlreadyCommitted(root) { return nil }
    return fmt.Errorf("block %d not committed: %w", block.Header.Number, err)
}

Prevention

When it happens

Trigger: CommitLegacy fails during StoreBlock — commonly committing a block number that was already committed, ledger write errors, state/validation DB outages, or a private-data mismatch rejected by the ledger.

Common situations: Peer replaying a block it already committed (duplicate commit after reconnect); disk full or corrupted LevelDB/CouchDB; gRPC-restarted committer double-delivering a block; underlying ledger returning internal errors.

Related errors


AI-assisted analysis of hyperledger/fabric@2736b63f8f (2026-09-04). Data as JSON: /api/errors/1c4aefef7ccb340b. Report an issue: GitHub.