hyperledger-archives / fabric

THIS IS A READ-ONLY historic repository. Current development is at https://gerrit.hyperledger.org/r/#/admin/projects/fabric . pull requests not accepted
https://gerrit.hyperledger.org/
Apache License 2.0
1.17k stars 1.01k forks source link

deploy transaction with same parameters should return error #581

Open muralisrini opened 8 years ago

corecode commented 8 years ago

Why? isn't it conceivable that you want to run two separate chaincode instances that are created the same way?

muralisrini commented 8 years ago

We need to separate instance (not there today) and deploy (which is a one time operation). Semantics of deploy is "one time" (it always returns the same "transaction id" as stored on the ledger).

Also when chaincode instance is implemented, each instance would need to be identified uniquely as well - but that's a different discussion.

binhn commented 8 years ago

@muralisrini I tried and succeeded in deploying a chaincode twice:

vagrant@vagrant-ubuntu-trusty-64:/opt/gopath/src/github.com/openblockchain/obc-peer$ OPENCHAIN_PEER_ADDRESS=10.0.2.15:30303 ./obc-peer chaincode deploy -p github.com/openblockchain/obc-peer/openchain/example/chaincode/chaincode_example02 -c '{"Function":"init", "Args":["a", "1", "b", "1"]}' --logging-level=info
15:01:51.623 [main] chaincodeDeploy -> INFO 001 Deploy result: type:GOLANG chaincodeID:<path:"github.com/openblockchain/obc-peer/openchain/example/chaincode/chaincode_example02" name:"bddbf5b909a9eacf97bfeaba9991b04a36dd5e437167f6bda6fbc0add4641d81b7eba987236acdf1a73d6742af1a0ada2b24b86123141708281504cd241fdbb8" > ctorMsg:<function:"init" args:"a" args:"1" args:"b" args:"1" > 
vagrant@vagrant-ubuntu-trusty-64:/opt/gopath/src/github.com/openblockchain/obc-peer$ OPENCHAIN_PEER_ADDRESS=10.0.2.15:30303 ./obc-peer chaincode deploy -p github.com/openblockchain/obc-peer/openchain/example/chaincode/chaincode_example02 -c '{"Function":"init", "Args":["a", "1", "b", "1"]}' --logging-level=info
15:02:41.237 [main] chaincodeDeploy -> INFO 001 Deploy result: type:GOLANG chaincodeID:<path:"github.com/openblockchain/obc-peer/openchain/example/chaincode/chaincode_example02" name:"bddbf5b909a9eacf97bfeaba9991b04a36dd5e437167f6bda6fbc0add4641d81b7eba987236acdf1a73d6742af1a0ada2b24b86123141708281504cd241fdbb8" > ctorMsg:<function:"init" args:"a" args:"1" args:"b" args:"1" > 
binhn commented 8 years ago

Change to sev3 since the user can control this

christo4ferris commented 8 years ago

@muralisrini I'm confused... is /deploy intended to be idempotent? If so, then the title and suggested fix) is incorrect. If indeed the expected behavior is as you say above: "Semantics of deploy is "one time" (it always returns the same "transaction id" as stored on the ledger)." then we don't want it to return an error, we want it to return the same transaction id.

That aside, bug reports should have information as to how to reproduce the error so that someone taking on the task of fixing has something with which to work. Binh's example code https://github.com/hyperledger/fabric/issues/581#issuecomment-182411613 should suffice for this one (although it needs to be transposed from openblockchain to hyperledger).

muralisrini commented 8 years ago

@christo4ferris : Agree I should have added details....

This issue is about how we should handle redeploys of an existing chaincode. The details of deploy are (1) create the image (2) launch the chaincode and (3) call "init". "init" is a one time operation signifying creation of chaincode, so by extension deploy should also be an one time operation. Currently we don't treat redeploy as an error.

There are two ways to handle error from redeploy

  1. detect duplicate upfront so we could return an error to caller immediately
  2. detect it at execution time and mark transaction as error (ie, user gets the usual transaction id as response .... this is consistent with @binhn's example code above)

Option 2 is is consistent with how "invoke" transaction's outcomes are handled. My preference would be for option 2.

Related Currently there is no proper "instance" support.When we do support it, users will be able to create instances of chaincode. That will also clarify the difference between current deploy and instantiate. Extensive discussion on instances in #373.

christo4ferris commented 8 years ago

@muralisrini where do we stand with this?