hyperledger / fabric-contract-api-go

Packages for the implementation of the contract API for use in Go chaincode
https://wiki.hyperledger.org/display/fabric
Apache License 2.0
218 stars 100 forks source link

If the chaincode input and output functions have different packages but the same structure name then variable conflict issue in the chaincode #109

Open JungHyeokChoi opened 10 months ago

JungHyeokChoi commented 10 months ago

Using spec

Literally, If the chaincode input and output functions have different packages but the same structure name then variable conflict issue in the chaincode.

Example

test1.go

package test1

type Test struct {
   A string `json:”a”`
}

test.go

package test

import (
   <path to>/test1
)

type Test struct {
   B int `json:”b”`
}

func(s *Contract) Test1(ctx contranctapi. TranscationContextInterface) (test1.Test) {}
func(s *Contract) Test2(ctx contranctapi. TranscationContextInterface) (Test) {}

In the case above, if Test2 is called after calling Test1, ‘Test’, the output of Test2, is recognized as ‘test1.Test’

If the structure name is different, no conflict will occur.

Please reply after confirmantion.

bestbeforetoday commented 10 months ago

I can confirm a similar error. I modified the asset-transfer-basic sample chaincode so that GetAllAssets return data.Asset while ReadAsset continued to return Asset. data.Asset was identical to Asset, except that all the JSON strings in data.Asset were lower cased instead of capitalised in Asset. I observed the following error when ReadAsset was called following a call to GetAllAssets:

failed to evaluate transaction: rpc error: code = Unknown desc = evaluate call to endorser returned error: chaincode response 500, Error handling success response. Value did not match schema:
1. return: Additional property AppraisedValue is not allowed
2. return: Additional property Color is not allowed
3. return: Additional property ID is not allowed
4. return: Additional property Owner is not allowed
5. return: Additional property Size is not allowed
6. return: appraisedValue is required
7. return: colour is required
8. return: id is required
9. return: owner is required
10. return: size is required
JungHyeokChoi commented 10 months ago

Yes, that’s the bug.

I forgot to write an error message.

May i know when it will be fixed?

bestbeforetoday commented 10 months ago

I prototyped a fix in pull request #118. It fails the contract metadata tests from the Fabric integration tests in fabric-test. I am not sure whether the change to the generated contract metadata is acceptable and the tests can be updated to be less specific about the element names present, or if the inconsistency across contract implementation languages is a blocker to this fix approach.

From an application perspective the workaround might be to ensure that you use uniquely (short) named data types as parameter and return values.

JungHyeokChoi commented 10 months ago

Ok, i understand.

I will fix it using the method you suggested.

Thanks for your help.