You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.
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
test.go
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.
The text was updated successfully, but these errors were encountered: