hyperledger/fabric · error

query failed with status: %d - %s

Error message

query failed with status: %d - %s

What it means

ReadinessCheck sends a CheckCommitReadiness proposal to a peer and expects a successful endorsement response. This error means the peer responded, but with a non-200 (non-SUCCESS) gRPC/protobuf status code in the ProposalResponse, and the response message is embedded in the error text. It is the CLI surfacing a peer-side rejection of the readiness query.

Source

Thrown at internal/peer/lifecycle/chaincode/checkcommitreadiness.go:186

		return errors.WithMessage(err, "failed to create signed proposal")
	}

	// checkcommitreadiness currently only supports a single peer
	proposalResponse, err := c.EndorserClient.ProcessProposal(context.Background(), signedProposal)
	if err != nil {
		return errors.WithMessage(err, "failed to endorse proposal")
	}

	if proposalResponse == nil {
		return errors.New("received nil proposal response")
	}

	if proposalResponse.Response == nil {
		return errors.New("received proposal response with nil response")
	}

	if proposalResponse.Response.Status != int32(cb.Status_SUCCESS) {
		return errors.Errorf("query failed with status: %d - %s", proposalResponse.Response.Status, proposalResponse.Response.Message)
	}

	if strings.ToLower(c.Input.OutputFormat) == "json" {
		// Unmarshal the proposal response to add descriptions to mismatch items
		readinessResult := &lb.CheckCommitReadinessResult{}
		err := proto.Unmarshal(proposalResponse.Response.Payload, readinessResult)
		if err != nil {
			return errors.Wrap(err, "failed to unmarshal readiness result")
		}

		if c.Input.InspectionEnabled {
			for org, mismatches := range readinessResult.Mismatches {
				for i, item := range mismatches.Items {
					mismatches.Items[i] = c.mismatchItemWithDescription(item)
				}
				readinessResult.Mismatches[org] = mismatches
			}
		} else {

View on GitHub (pinned to 2736b63f8f)

Solutions

1. Read the %s message in the error to see the peer's rejection reason and fix that root cause
2. Verify --channelID and --name match an existing channel and chaincode definition
3. Check MSP/identity configuration so the submitting client is authorized on the channel
4. Try a different --peerAddress in case the target peer is unhealthy

Example fix

// before
peer lifecycle chaincode checkcommitreadiness --channelID wrongchan --name mycc --signature-policy ...
// after
peer lifecycle chaincode checkcommitreadiness --channelID mychannel --name mycc --signature-policy ...

// check channel and chaincode exist before invoking
if channelID == "" || chaincodeName == "" { return errors.New("channelID and name are required") }

if resp.GetResponse() == nil || resp.Response == nil { return errors.New("nil proposal response") }

err := checker.ReadinessCheck(); if err != nil { var status int32; if strings.HasPrefix(err.Error(), "query failed with status:") { fmt.Sscanf(err.Error(), "query failed with status: %d", &status); log.Printf("peer rejected with status %d", status) } else { return err } }

When it happens

Trigger: Running `peer lifecycle chaincode checkcommitreadiness` when the peer rejects the proposal: bad channel name, chaincode not defined on the channel, authorization/signature failure, or the peer returns an error status like 500 with a message.

Common situations: Misspelled --channelID or --name; user not enrolled/authorized on the channel; endorsing peer down or in a bad state returning 503/500; chaincode package name/sequence mismatch against the committed definition.

Related errors

• only applicable for private data
• unknown operation type
• error reading chaincode install package at %s
• chaincode %s exists
• instantiation policy cannot be nil for chaincode (%s:%s)

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