Transaction Promise Timeout Error

149 views Asked by At

I'm trying to dynamically create a Peer (participant) through a transaction enrollPeer. I want the chaincode to generate the peerIDs on its own by getting num of peers and adding 1.

I am getting a timeout when I let the chaincode create a peerID on it's own. When I pass the peerID in the transaction (optional field), it sucessfully gets added to the registry. Is there a problem with how I am resolving my promises?

function enrollNewPeer(enroll){
    var factory = getFactory();
    var NS = 'org.acme.destro';

    if(enroll.typeOfPeer == null){
        enroll.typeOfPeer = 'Peer';
    }

    /* Make sure type exists */
    enroll.typeOfPeer = 'Peer';
    /* Make sure peerID does not exist */
    return getParticipantRegistry(NS + '.Peer')
    .then(function (peerRegistry) {            
        return peerRegistry.exists(enroll.peerID);  
    }).then(function (assetFound) {
        if (assetFound) {
            throw new Error("Peer Already Exitsts");
        }
        if(enroll.peerID == null){
            getParticipantRegistry(NS + '.Peer')
            .then(function (peerRegistry) {            
                return peerRegistry.getAll(); //returns list of Peers
            }).then(function(allPeers){ 
                var peerNum = (allPeers.length) + 1; // get #of peers and add 1
                var event = factory.newEvent(NS,'numPeers');
                event.peers = peerNum;
                emit(event);
            }).then(function() {
                enroll.peerID = 'peer' + peerNum;
            });
        }
    }).then(function() {
        var peer = factory.newResource(NS, enroll.typeOfPeer, enroll.peerID);
        peer.peerPubKey = assignKey(peer.peerID);

        var event = factory.newEvent(NS,'newPeer');
        event.peer = peer;
        emit(event);

        return getParticipantRegistry(NS + '.' + enroll.typeOfPeer)
        .then(function(participantRegistry) {
            return participantRegistry.add(peer);
        });
    });
}
1

There are 1 answers

0
Dan Selman On BEST ANSWER

Your logic to get the number of peers and then add 1 is likely to fail once you run across multiple peers in a true distributed network. Each Fabric peer is going to query the number of peers and there's likely to be a race-condition where different peers get different values -- causing the transaction to get rolled back due to consensus failure. You should allocate the "new peer ID" on the client and pass it in with the transaction - this will ensure that all Fabric peers use the same id.