If the chaincode input and output functions have different packages but the same structure name then variable conflict issue in the chaincode
Using spec
- Mac Book Pro M1 Ventura v13.5.1
- Docker v24.0.6
- Hyperledger Fabric v2.5.3
- fabric-sdk-go v1.0.0
- fabric-contract-api-go v1.2.1
- fabric-chaincode-go v0.0.0-20230228194215-b84622ba6a7a
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.
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
Yes, that’s the bug.
I forgot to write an error message.
May i know when it will be fixed?
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.
Ok, i understand.
I will fix it using the method you suggested.
Thanks for your help.