Skip to content

Commit 4625030

Browse files
committedMar 14, 2018
[FAB-8844] correct handling of launch errors
An error during launch is incorrectly handled by partial deregistration. This error maybe benign and ignored by system, thus causing the deregistration to leave it in an inconsitent state where it believes the chaincode is not registered (and running) when it actually is. This causes subsequent invoke to attempt to restart. The fix is to have errors handled at the right decision point with existing error mechanism naturally handling them.. Change-Id: I9c655a5355991b2426b88986aa7da1f7145ba15e Signed-off-by: Srinivasan Muralidharan <srinivasan.muralidharan99@gmail.com>
1 parent b15a54e commit 4625030

File tree

1 file changed

+5
-3
lines changed

1 file changed

+5
-3
lines changed
 

‎core/chaincode/chaincode_support.go

+5-3
Original file line numberDiff line numberDiff line change
@@ -494,10 +494,12 @@ func (chaincodeSupport *ChaincodeSupport) launchAndWaitForRegister(ctxt context.
494494
if err == nil {
495495
err = resp.Err
496496
}
497+
498+
//if the launch was successful and leads to proper registration,
499+
//this error could be ignored in the select below. On the other
500+
//hand the error might be triggered for select in which case
501+
//the launch will be cleaned up
497502
err = errors.WithMessage(err, "error starting container")
498-
chaincodeSupport.runningChaincodes.Lock()
499-
delete(chaincodeSupport.runningChaincodes.chaincodeMap, canName)
500-
chaincodeSupport.runningChaincodes.Unlock()
501503
}
502504
}()
503505

0 commit comments

Comments
 (0)
Please sign in to comment.