hyperledger/fabric · error

timestamp is nil

Error message

timestamp is nil

What it means

validateAliveMessage requires AliveMsg.Timestamp (a peer time structure) to be present; discovery uses it to detect liveness. A nil timestamp means the AliveMessage cannot be freshness-checked, so the message is rejected.

Source

Thrown at discovery/client/client.go:584

// NewClient creates a new Client instance
func NewClient(createConnection Dialer, s Signer, signerCacheSize uint) *Client {
	return &Client{
		createConnection: createConnection,
		signRequest:      NewMemoizeSigner(s, signerCacheSize).Sign,
	}
}

func validateAliveMessage(message *gprotoext.SignedGossipMessage) error {
	am := message.GetAliveMsg()
	if am == nil {
		return errors.New("message isn't an alive message")
	}
	m := am.Membership
	if m == nil {
		return errors.New("membership is empty")
	}
	if am.Timestamp == nil {
		return errors.New("timestamp is nil")
	}
	return nil
}

func validateStateInfoMessage(message *gprotoext.SignedGossipMessage) error {
	si := message.GetStateInfo()
	if si == nil {
		return errors.New("message isn't a stateInfo message")
	}
	if si.Timestamp == nil {
		return errors.New("timestamp is nil")
	}
	if si.Properties == nil {
		return errors.New("properties is nil")
	}
	return nil
}

View on GitHub (pinned to 2736b63f8f)

Solutions

  1. Check NTP/PTP time synchronization on the peer host and restart the peer
  2. Verify Fabric version compatibility across peers
  3. Inspect gossip logs for alive-message construction errors
  4. Retry discovery against a healthy peer
Defensive patterns

Strategy: validation

Validate before calling

func aliveMsgHasTimestamp(m *gprotoext.SignedGossipMessage) bool {
    am := m.GetAliveMsg()
    return am != nil && am.Timestamp != nil
}

Type guard

func hasAliveTimestamp(m *gprotoext.SignedGossipMessage) bool {
    am := m.GetAliveMsg()
    return am != nil && am.Timestamp != nil
}

Try / catch

if err != nil && strings.Contains(err.Error(), "timestamp is nil") {
    logger.Warnf("peer alive message lacks timestamp; possible clock/gossip issue")
    return err
}

Prevention

When it happens

Trigger: A discovery response AliveMsg lacks its Timestamp field — malformed membership data from the peer.

Common situations: Peer clocks / gossip time sync problems (internal timestamp construction failed); corrupted gossip payloads; old Fabric versions emitting different alive message layouts.

Related errors


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