Hyperledger Fabric背书失败仍更新状态数据库及Composer实验异常咨询

Hey there, let’s dig into the two issues you’re hitting with Hyperledger Fabric and Composer—they share some common root causes but have framework-specific twists to address.

1. Hyperledger Fabric: Endorsement Failure Yet State Database Gets Updated #

First, let’s recap Fabric’s transaction flow to set context: when you submit a transaction, client apps send a proposal to endorsement peers, which simulate the transaction and generate a read-write set. Only if the endorsement passes (matches the chaincode’s endorsement policy) should the client send the transaction to the orderer. The orderer packages it into a block, which peers then validate—only valid transactions update the world state.

If you’re seeing state updates despite endorsement failures, here’s what to check:

• Client code isn’t checking endorsement responses properly
  This is the most common culprit. Many devs forget to verify that all required endorsement peers returned a SUCCESS status before sending the transaction to the orderer. For example, in the Node SDK, you need to iterate through proposalResponses and ensure every response from required peers has response.status === 200. If you skip this check, you’ll end up submitting invalid transactions to the orderer, which gets packaged into blocks. Peers might still mark the transaction as invalid, but if you’re querying the endorsement peer that simulated the transaction (not a peer that validated the block), you might see the temporary simulated state—make sure you query a peer that’s received the finalized block.

• Endorsement policy is misconfigured
  Double-check your chaincode’s endorsement policy. Maybe the policy is looser than you think (e.g., OR('Org1MSP.peer') instead of AND('Org1MSP.peer', 'Org2MSP.peer')), so even if one peer fails, another’s endorsement satisfies the policy. You can query the policy with:

  peer chaincode query -C your-channel -n your-chaincode -c '{"Args":["getPolicy"]}'
  

• Peer node validation is skipped
  Rare, but check if your peer has peer.gossip.state.enabled set to false (in core.yaml). This disables state validation during block commit, which would let invalid transactions update the world state. Also, ensure you’re running a stable Fabric version—older versions (pre-1.4) had edge cases where invalid transactions could slip through.

• Verify transaction final status
  Use this command to check if the transaction was actually marked valid or invalid:

  peer channel queryTx -C your-channel -t <transaction-id>
  

  If it shows INVALID but the state is updated, you might hit a rare bug—try upgrading to the latest patch of your Fabric version.

2. Hyperledger Composer: Endorsement Policy Failure Yet Blocks Are Generated & State Updates #

Composer sits on top of Fabric, so many of the above checks apply, but there are Composer-specific quirks to investigate:

• Composer’s transaction submission logic
  Composer’s submitTransaction method might be swallowing endorsement errors if you’re not handling exceptions properly. Make sure you’re wrapping the call in a try/catch block and checking for errors before assuming success. For example:

  try {
    await businessNetworkConnection.submitTransaction('YourTransaction', args);
  } catch (err) {
    console.error('Endorsement or submission failed:', err);
    // Don't proceed if there's an error!
    throw err;
  }
  

• ACL and endorsement policy mismatch
  Composer’s permissions.acl defines who can execute transactions, but this doesn’t replace Fabric’s endorsement policy. If your ACL allows a user to run a transaction, but the underlying chaincode’s endorsement policy requires multiple peers, Composer might only collect one endorsement (leading to a policy failure log) but still submit the transaction. Ensure your ACL rules align with the chaincode’s endorsement policy—if the policy needs two orgs, your ACL should restrict the transaction to users from those orgs.

• Debug Composer logs
  Enable debug logging to see exactly what’s happening during endorsement. Set the DEBUG environment variable before running your Composer app:

  DEBUG=composer* node your-app.js
  

  Look for lines like Endorsement failed or Submitting transaction to orderer to confirm if the client is submitting despite failures.

• Check Fabric’s underlying transaction status
  Same as the Fabric issue—use peer channel queryTx to see if the transaction is marked valid. If it’s valid, the "policy failure" log might be a red herring (e.g., one peer failed to endorse, but enough others passed to meet the policy).

内容的提问来源于stack exchange，提问作者user9040429