Closed CaptainIRS closed 7 months ago
Merging #1465 (35873cf) into main (943ab2a) will not change coverage. The diff coverage is
n/a
.:exclamation: Current head 35873cf differs from pull request most recent head fffa938. Consider uploading reports for the commit fffa938 to get more accurate results
@@ Coverage Diff @@
## main #1465 +/- ##
=======================================
Coverage 55.89% 55.89%
=======================================
Files 105 105
Lines 4507 4507
Branches 688 688
=======================================
Hits 2519 2519
Misses 1435 1435
Partials 553 553
Flag | Coverage Δ | |
---|---|---|
caliper-core | 44.98% <ø> (ø) |
|
caliper-fabric | 80.46% <ø> (ø) |
|
generator-caliper | 83.62% <ø> (ø) |
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
@CaptainIRS
@CaptainIRS the errors are very odd and the fact they happen in both 1.4 and 2.2 node sdks only with microfab. Not surprised with the fabric-gateway as it does event handing differently. I'll see if I can get someone to look at it too.
Hello @CaptainIRS ... I've been trying to recreate this problem with Microfab, without much success I'm afraid. I believe that (logically) there are 2 processes, each running an application sending transactions. Is each just doing one org are does it swap?
I've got two apps here that are using the 2.2 NodeSDK submitting transactions to microfab; it seems completely stable.
Chaincode Signature Policy is --signature-policy "OR('org1MSP.peer','org2MSP.peer')"
Microfab config
"endorsing_organizations":[
{
"name": "org1"
},
{
"name": "org2"
}
],
"channels":[
{
"name": "mychannel",
"endorsing_organizations":[
"org1","org2"
]
}
],
"capability_level":"V2_0"
}'
@CaptainIRS found the problem!!
For microfab the asLocalhost
setting must be false. Irrespective of the fact it is local... it needs the full hostnames.
caliper:
fabric:
gateway:
localhost: false
Added that to my local caliper configuration caliper.yaml
and all is well.
Thank you @mbwhite for investigating. @CaptainIRS Best way is to add
--caliper-fabric-gateway-localhost false
when launching caliper eg
${CALL_METHOD} launch manager --caliper-workspace phase4 --caliper-flow-only-test --caliper-fabric-gateway-localhost false
It's interesting that microfab appears to work using the legacy sdks when localhost is set to true for a lot of the time so definitely something that microfab should document. I thought it used hostname for routing and as the endpoint urls get translated to localhost:8080 I wasn't expecting that to work at all. The problem was that the endorsers were being discovered and the endpoints were being translated to the same endpoint of localhost:8080 from org1peer-api.127-0-0-1.nip.io:8080 and org2peer-api.127-0-0-1.nip.io:8080 and thus you could only have one at that endpoint so in some cases was being loaded with the wrong peer for the mspid of the identity. I also suspect that if the chaincode had an AND endorsement policy it would have failed for all submissions as it wouldn't be able to get all endorsements as there would only be 1 endorser in the channel object.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Closing this pull request because microfab is has gone dormant with the maintainers now not involved in hyperledger fabric anymore and it's unlikely to be maintained in the future.
Some issues/notes as of now:
There seems to be an issue selecting the correct endorsing peers when using the older Fabric SDK (works well using the newer Fabric Gateway API though)Normal installation of chaincode doesn't seem to work in microfab (can only install using CCAS)