hyperledger/fabric · error

tx type [%s] is not expected

Error message

tx type [%s] is not expected

What it means

GenerateSimulationResults only handles HeaderType_CONFIG transactions for the peer's channel-config simulation. Any other transaction type falling into the default branch produces this formatted error identifying the unexpected type.

Source

Thrown at core/peer/configtx_processor.go:42

// ConfigTxProcessor implements the interface 'github.com/hyperledger/fabric/core/ledger/customtx/Processor'
type ConfigTxProcessor struct{}

// GenerateSimulationResults implements function in the interface 'github.com/hyperledger/fabric/core/ledger/customtx/Processor'
// This implementation processes CONFIG transactions which simply stores the config-envelope-bytes
func (tp *ConfigTxProcessor) GenerateSimulationResults(txEnv *common.Envelope, simulator ledger.TxSimulator, initializingLedger bool) error {
	payload := protoutil.UnmarshalPayloadOrPanic(txEnv.Payload)
	channelHdr := protoutil.UnmarshalChannelHeaderOrPanic(payload.Header.ChannelHeader)
	txType := common.HeaderType(channelHdr.GetType())

	switch txType {
	case common.HeaderType_CONFIG:
		peerLogger.Debugf("Processing CONFIG")
		if payload.Data == nil {
			return errors.New("channel config found nil")
		}
		return simulator.SetState(peerNamespace, channelConfigKey, payload.Data)
	default:
		return fmt.Errorf("tx type [%s] is not expected", txType)
	}
}

func retrieveChannelConfig(queryExecuter ledger.QueryExecutor) (*common.Config, error) {
	configBytes, err := queryExecuter.GetState(peerNamespace, channelConfigKey)
	if err != nil {
		return nil, err
	}
	if configBytes == nil {
		return nil, nil
	}
	configEnvelope := &common.ConfigEnvelope{}
	if err := proto.Unmarshal(configBytes, configEnvelope); err != nil {
		return nil, err
	}
	return configEnvelope.Config, nil
}

View on GitHub (pinned to 2736b63f8f)

Solutions

1. Route only HeaderType_CONFIG payloads to GenerateSimulationResults; dispatch other types to their own processors.
2. Inspect common.HeaderType(hdr.Type) upstream and skip/filter non-CONFIG txs.
3. If you intended to simulate normal txs, use the appropriate tx validator/simulator path, not the config processor.

Example fix

// before
sim.GenerateSimulationResults(anyPayload) // any tx type
// after
if common.HeaderType(channelHdr.GetType()) == common.HeaderType_CONFIG {
  sim.GenerateSimulationResults(anyPayload)
} else {
  // handle via default endorser tx path
}

if common.HeaderType(payload.Header.ChannelHeader.Type) != common.HeaderType_CONFIG {
  return errors.New("only CONFIG txs accepted here")
}

func isConfigTx(hdr *common.ChannelHeader) bool {
  return hdr != nil && common.HeaderType(hdr.Type) == common.HeaderType_CONFIG
}

if err := sim.GenerateSimulationResults(payload); err != nil && strings.Contains(err.Error(), "is not expected") {
  log.Printf("wrong tx type routed to config processor: %v", err)
}

When it happens

Trigger: Calling GenerateSimulationResults with a payload whose header type is not CONFIG (e.g., ENDORSER_TRANSACTION, CONFIG_UPDATE) — the processor is only meant for channel-config simulation.

Common situations: Reusing the configtx simulation processor on regular endorsement transactions by mistake; wiring a generic block/payload stream into the config processor; tests feeding arbitrary tx types.

Related errors

• channel config found nil
• organization %s not found
• error decoding the block number
• error decoding the data hash
• error decoding the previous hash

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