Currently chaincode events in hyperledger will only raise duplicate events n number of times, where n is the number of chaincode events in a block and the event raised is the first event in the block.
const profileRegId = this.event_hub.registerChaincodeEvent(request.chaincodeId, "Profile Added", event => {
this.event_hub.unregisterChaincodeEvent(profileRegId);
em.emit(event.payload);
});
Above is how we are calling the registerChaincodeEvent function in our node application.
createEvent(APIstub, "Profile Added", profile)
Above is how we implement in the chaincode.
Is there a way to raise this as a bug with hyperledger myself?
The procedure of opening a new bugs or submitting issues into Hyperledger Fabric is fairly simple, you need to register your linux foundation id (read here the details) and login into https://jira.hyperledger.org/, once done you can open an issue.
While from your description it's not really clear/obvious there is an issue, if you have n valid transactions each has created an event not sure whenever it was expected to have only single notification. Also please note, since release of v1.1.0 of Fabric there is a new event delivery service: FAB-7069 and here some docs about it.
However, if you still think there is a bug or possible improvement, please submit JIRA.
Related
I am currently running hyperledger fabric v2.2. I have developed the chaincode using the contractapi and developing the application using fabric-sdk-go/pkg/gateway
How can i get the transaction status and the transaction payload? I am aware of the GetHistoryByKey() which is available in the contractapi but that doesn't works out for my application.
I know there is hyperledger-explorer which can be used to search transactions by TxID but my use-case is my application will be querying by TxID and then it will verify the status of that particular transaction (TxID).
Also, i have tried to achieve this using the fabsdk but i am getting an error when i try to create instantiate the fabsdk using the fabsdk.New(). There seems to be some compatibility issue with the connection-profile.json which i am using the fabric-sample project.
The error which i am getting is:
failed to create identity manager provider: failed to initialize identity manager for organization: MyOrgName: Either a cryptopath or an embedded list of users is required
The same connection-profile has been used in getting the network up and running, and everything seems to be working all good. I am able to submit and evaluate transactions.
SOLUTION
The system chaincodes are embedded in the peer itself. so we need to set the target otherwise it would just give the discovery error since the contract QSCC is not explicitly deployed on the channel.
Make sure to check the core.yaml file channel.system - the system chaincode should be enabled channel.system.qscc: enable
qsccContract := network.GetContract("qscc")
txn, err := qsccContract.CreateTransaction("GetTransactionByID", gateway.WithEndorsingPeers("peer0.org1.com:8051"))
if err != nil {
fmt.Printf("Failed to create transaction: %s\n", err)
return
}
result, err := txn.Evaluate("mychannel", "4b1175335bdfe074d516a69df180ed6bc14591543eb26c10e21df2c67602b2dc")
if err != nil {
fmt.Printf("Failed to submit transaction: %s\n", err)
return
}
fmt.Println(string(result))
Note: The result needs to decoded to be human readable
Your client application can use the client SDK appropriate to your pogramming language to evaluate the GetTransactionByID transaction function on the qscc system chaincode, which is available on all peers. This transaction function takes a transaction ID as its only argument and returns a peer.ProcessedTransaction protobuf, which contains the transaction envelope and a validation code.
I want to create a wallet for new rest api server, but whenever I call code to generate new Wallet I'm getting error like
"Decoding SignatureHeader failed: Error illegal buffer ..."
Here is screen shot of my code, it is taken from virtual machine
I'm using hyperledger fabric 2.2 and run under the fabric-samples/test-network
I was clone this HyperledgerFabroc
Here is also print screen of the error:
I would appreciate if someone can navigate me how to manage successfully to create a wallet ?
Your error looks to be occurring within a chaincode transaction function. You should not be using the client SDK to do a transaction invocation from within chaincode. Instead look to use the invokeChaincode function on the stub:
https://hyperledger.github.io/fabric-chaincode-node/release-1.4/api/fabric-shim.ChaincodeStub.html#invokeChaincode
I am using client.channel.Execute API in fabric-sdk-go to invoke the ledger update Txs in chaincode.
I know my chaincode for ledger update is correct because invoke Tx when run from cli container command line is working perfectly all the times.
Few times, randomly, ledger updates are not reflecting when executed as REST API call from POSTMAN like below. In those cases, response code is 200 with correct response payload suggestive of successful chaincode running.
`
chaincodeID := "hcc"
fcn := "GiftToken"
args := [][]byte{
[]byte(reqBody.TokenID),
[]byte(reqBody.GiftToUserID),
[]byte(GiftTokenCountAsString),
}
setup := lib.GetFabricSetup()
transientDataMap := make(map[string][]byte)
transientDataMap["result"] = []byte("Transient data in GiftToken invoke")
response, err := setup.Client.Execute(channel.Request{ChaincodeID: chaincodeID, Fcn: fcn, Args: args, TransientMap: transientDataMap})
I am running Fabric 1.4.4 images in docker containers. My network has 1 org with 4 peer nodes.
Surely missing some aspect which is leading to this sort of behaviour.
Thanks in advance.
It takes time for all peers to sync their blocks. Once peers receive these blocks they update their world state, so you can see your change via querying.
When you query for the "just executed" transaction, you may hit one of other peers. If you want immediate result, ensure that you're querying the same peer(s) where you actually executed your transaction. You may try putting some delay to see other peers as well get the block.
The reason why you see the change immediately on CLI, is about the way of the client implementation. On CLI command execution, you specify the peer explicitly. So transaction is executed on one peer and queried on the same peer (no issues). You may prove this behavior by immediately querying (via CLI) another organization's peer just after you execute the transaction (via CLI).
However with your client, probably since you don't explicitly specify the peer, your client SDK uses peers' discovery service and find a peer in the network for you and use it.
Due to this reason, when endorsement policy is formed like "AND(org1, org2)", client SDK actually queries 2 peers (one each org) and compare results.
I got to the project that is based on BYFN sample, but limited to one organization only.
In the app when I call following code:
private Contract getContract(Gateway gw) {
return gw.getNetwork("mychannel").getContract("realchain");
}
following error is produced:
2019-10-30 09:34:51.433 INFO 23108 --- [nio-8080-exec-3] org.hyperledger.fabric.gateway.Gateway : Unable to load channel configuration from connection profile:
org.hyperledger.fabric.sdk.exception.NetworkConfigurationException: Channel configuration has no channels defined.
at org.hyperledger.fabric.sdk.NetworkConfig.loadChannel(NetworkConfig.java:519) ~[fabric-sdk-java-1.4.5-20190620.151745-1.jar:na]
at org.hyperledger.fabric.sdk.HFClient.loadChannelFromConfig(HFClient.java:161) ~[fabric-sdk-java-1.4.5-20190620.151745-1.jar:na]
at org.hyperledger.fabric.gateway.impl.GatewayImpl.getNetwork(GatewayImpl.java:258) ~[fabric-gateway-java-1.4.0-20191002.055106-31.jar:na]
...
...the app recovers somehow itself, but I suspect this error to slow down the whole interaction with the ledger.
Also I'd love to keep my logs clean from any exceptions if possible.
Anyone encountered and resolved the same error?
That is normal behaviour. If the connection profile does not contain a channel definition then the client uses peer definitions (currently for your client identity's organisation only) and assumes the channel exists for those peers. It should not impact performance at all.
You have the option of adding a channel definition to the connection profile, which will avoid this log message occurring, but we wanted to avoid this being necessary.
I agree that the exception appearing in the log gives the false impression that a real error has occurred and I have removed that in the current development code.
Migration of Ordering service from Kafka to Raft.
As we understand the Ordering service never signs the transaction in Fabric. Dose this migration will effect anything on old transaction ordered by old ordere?
Also when we query transaction(local peer query), why do we set the orderer flag?
As long as you have successfully migrated consensus type from kafka >> raft
You are allowed to proceed with transactions.
Question1: Ordering service never signs the transaction in Fabric
Endorsing peers alone will sign transactions & orderer signs the blocks
Question2: Dose this migration will effect anything on old transaction ordered by old ordere?
No, If migration is successful then you are OK to proceed
If you would have followed this link and complete without errors https://hyperledger-fabric.readthedocs.io/en/release-1.4/kafka_raft_migration.html
THEN OK, dont worry about previous data, All SAFE.
However, let me know if you need any assistance in migration. Feel free to create another question reg: migration.
If you want to see old blocks after migration
check this snippet
// keep the block_reg to unregister with later if needed
block_reg = channel_event_hub.registerBlockEvent((block) => {
console.log('Successfully received the block event');
<do something with the block>
}, (error)=> {
console.log('Failed to receive the block event ::'+error);
<do something with the error>
},
{startBlock:23}
);
startBlock:{can be any Block No}
check > https://fabric-sdk-node.github.io/tutorial-channel-events.html
you will get complete block as json format, you will have orderer signature so that you can check which orderer has sealed this block.