hyperledger/fabric · error

failed to submit request

Error message

failed to submit request

What it means

This error is returned by BFTChain.submit when c.consensus.SubmitRequest(reqBytes) rejects the marshaled request, wrapping the underlying consensus error. It means the SmartBFT engine itself refused to enqueue the request — typically because the node is not the leader, is catching up, or the internal consensus queue is unavailable/closed.

Source

Thrown at orderer/consensus/smartbft/chain.go:323

func (c *BFTChain) pruneBadRequests() {
	c.consensus.Pool.Prune(func(req []byte) error {
		_, err := c.consensus.Verifier.VerifyRequest(req)
		return err
	})
}

func (c *BFTChain) submit(env *cb.Envelope) error {
	if env == nil {
		return errors.New("failed to marshal request envelope: proto: Marshal called with nil")
	}
	reqBytes, err := proto.Marshal(env)
	if err != nil {
		return errors.Wrapf(err, "failed to marshal request envelope")
	}

	c.Logger.Debugf("Consensus.SubmitRequest, node id %d", c.Config.SelfID)
	if err = c.consensus.SubmitRequest(reqBytes); err != nil {
		return errors.Wrapf(err, "failed to submit request")
	}
	return nil
}

// Order accepts a message which has been processed at a given configSeq.
// If the configSeq advances, it is the responsibility of the consenter
// to revalidate and potentially discard the message
// The consenter may return an error, indicating the message was not accepted
func (c *BFTChain) Order(env *cb.Envelope, configSeq uint64) error {
	seq := c.support.Sequence()
	if configSeq < seq {
		c.Logger.Warnf("Normal message was validated against %d, although current config seq has advanced (%d)", configSeq, seq)
		if _, err := c.support.ProcessNormalMsg(env); err != nil {
			return errors.Errorf("bad normal message: %s", err)
		}
	}

	return c.submit(env)

View on GitHub (pinned to 2736b63f8f)

Solutions

1. Inspect the wrapped error from SubmitRequest to see the exact consensus failure reason
2. Retry the broadcast after a short delay — during view change/leader failover requests are transiently rejected
3. Verify the node's BFT config (SelfID, cluster membership) matches other nodes so leadership elections succeed
4. Check chain halt/shutdown ordering in your code; do not submit after Chain.Start errors or during Close

Example fix

// before
if err := chain.Order(env, seq); err != nil { return err } // failed to submit request

// after
var err error
for i := 0; i < 3; i++ {
    if err = chain.Order(env, seq); err == nil || !strings.Contains(err.Error(), "failed to submit request") { break }
    time.Sleep(500 * time.Millisecond)
}

// Pre-flight: ensure chain is running and node is active before submitting
if !chainStarted.Load() { return errors.New("chain not started") }
// Optionally skip submit when this node is known to be mid-view-change
if consensusState() == StateViewChange { return errors.New("view change in progress, retry later") }

var err error
for i := 0; i < 5; i++ {
    if err = chain.Order(env, seq); err == nil { return nil }
    if !strings.Contains(err.Error(), "failed to submit request") { return err }
    time.Sleep(time.Duration(1<<i) * 100 * time.Millisecond)
}
return err

When it happens

Trigger: Calling Order() or Configure() after the BFT chain has started but the underlying consensus instance fails SubmitRequest — e.g. the node just lost leadership, the chain is being halted, view-change in progress, or the request queue is full.

Common situations: Leader failover/view change while clients keep broadcasting; ordering node being shut down mid-traffic; requests arriving before the chain finished starting; consensus internals wedged after network partition.

Related errors

• got unexpected status: %v -- %s
• node id mismatch
• channel %s doesn't exist
• faulty node, received: %v
• not in the channel

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