hyperledger/fabric · error

invalid transaction type %d

Error message

invalid transaction type %d

What it means

CreateProcessor looks up a registered processor for the transaction's header type (common.HeaderType) in the factory's ProcessorCreators map. If no creator is registered for that type, it returns an InvalidErr with message 'invalid transaction type %d' and TxValidationCode_UNKNOWN_TX_TYPE. Only ENDORSER_TRANSACTION and CONFIG (and their processors) are typically registered.

Source

Thrown at core/tx/processor_factory.go:36

// ProcessorFactory maintains a mapping between transaction type and associate `ProcessorCreator`
type ProcessorFactory struct {
	ProcessorCreators map[common.HeaderType]tx.ProcessorCreator
}

// CreateProcessor unmarshals bytes into an Envelope and invokes a ProcessorCreators corresponding to the transaction type
// present in the ChannelHeader. If successful, this function returns the Processor and simulatedRWSet created by the ProcessorCreators.
// However, if this function encounters and error in detecting the transaction type or a
// ProcessorCreators has not been registered for the transaction type, the error returned would be of type
// `tx.InvalidErr` which implies that the transaction is found to be invalid at the very beginning stage
func (f *ProcessorFactory) CreateProcessor(txEnvelopeBytes []byte) (processor tx.Processor, simulatedRWSet [][]byte, err error) {
	txEnv, err := validateProtoAndConstructTxEnv(txEnvelopeBytes)
	if err != nil {
		return nil, nil, err
	}
	c, ok := f.ProcessorCreators[common.HeaderType(txEnv.ChannelHeader.Type)]
	if !ok {
		return nil, nil, &tx.InvalidErr{
			ActualErr:      errors.Errorf("invalid transaction type %d", txEnv.ChannelHeader.Type),
			ValidationCode: peer.TxValidationCode_UNKNOWN_TX_TYPE,
		}
	}
	return c.NewProcessor(txEnv)
}

// validateProtoAndConstructTxEnv attempts to unmarshal the bytes and prepare an instance of struct tx.Envelope
// It returns an error of type `tx.InvalidErr` if the proto message is found to be invalid
func validateProtoAndConstructTxEnv(txEnvelopeBytes []byte) (*tx.Envelope, error) {
	txenv, err := protoutil.UnmarshalEnvelope(txEnvelopeBytes)
	if err != nil {
		return nil, &tx.InvalidErr{
			ActualErr:      err,
			ValidationCode: peer.TxValidationCode_INVALID_OTHER_REASON,
		}
	}

	if len(txenv.Payload) == 0 {

View on GitHub (pinned to 2736b63f8f)

Solutions

1. Set ChannelHeader.Type to the correct value (common.HeaderType_ENDORSER_TRANSACTION = 3 for normal invokes) before submitting.
2. Register a custom processor via NewProcessorFactory/ProcessorCreators if you intentionally support a new tx type.
3. In tests, use the peer's test helpers (e.g. txtestutils) that populate a valid type.

Example fix

// before
chdr := &common.ChannelHeader{ChannelId: "mychannel"}
// after
chdr := &common.ChannelHeader{ChannelId: "mychannel", Type: int32(common.HeaderType_ENDORSER_TRANSACTION)}

if common.HeaderType(chdr.Type) != common.HeaderType_ENDORSER_TRANSACTION && common.HeaderType(chdr.Type) != common.HeaderType_CONFIG { return fmt.Errorf("unsupported tx type %d", chdr.Type) }

func supportedTxType(t int32) bool { ht := common.HeaderType(t); return ht == common.HeaderType_ENDORSER_TRANSACTION || ht == common.HeaderType_CONFIG }

// caller of CreateProcessor
proc, err := f.CreateProcessor(txEnv)
var ierr *tx.InvalidErr
if errors.As(err, &ierr) && ierr.ValidationCode == peer.TxValidationCode_UNKNOWN_TX_TYPE {
    // handle unknown tx type: skip/reject envelope
}

When it happens

Trigger: Passing a transaction envelope whose ChannelHeader.Type is 0 (unset), or a type like STATUS_UPDATE/PEER_RESOURCE_UPDATE that has no registered processor creator.

Common situations: Constructing test envelopes with a zero-valued ChannelHeader (Type defaults to 0); misconfigured system chaincode invocations; envelopes copied from a different network component with unexpected types.

Related errors

• error unmarshalling ChaincodeHeaderExtension
• nil ChaincodeId in header extension
• nil ChaincodeId in ChaincodeAction
• invalid chaincode ID
• inconsistent ccid info (%s/%s)

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