Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get proposal response payload from chaincode action #206

Merged
merged 1 commit into from
Feb 11, 2022

Conversation

bestbeforetoday
Copy link
Member

This is the correct chaincode transaction response payload location. The response payload field is intended to contain metadata but the peer currently copies the transaction response payload here for convenience. This causes failures due to gRPC message size limits for large response payloads and so may be removed in the future.

Also changed a few build scripts to honour the GO_CMD environment variable.

@codecov
Copy link

codecov bot commented Dec 2, 2021

Codecov Report

Merging #206 (1c61898) into main (4f34271) will increase coverage by 0.02%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #206      +/-   ##
==========================================
+ Coverage   76.09%   76.11%   +0.02%     
==========================================
  Files         193      193              
  Lines       14064    14078      +14     
==========================================
+ Hits        10702    10716      +14     
  Misses       2393     2393              
  Partials      969      969              
Impacted Files Coverage Δ
pkg/client/channel/invoke/txnhandler.go 84.04% <100.00%> (+1.49%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4f34271...1c61898. Read the comment docs.

@bestbeforetoday bestbeforetoday marked this pull request as ready for review December 2, 2021 16:31
@bestbeforetoday bestbeforetoday requested a review from a team as a code owner December 2, 2021 16:31
requestContext.Response.Payload = transactionProposalResponses[0].ProposalResponse.GetResponse().Payload
responsePayload, err := getResultFromProposalResponse(transactionProposalResponses[0].ProposalResponse)
if err != nil {
requestContext.Error = err
Copy link
Member Author

@bestbeforetoday bestbeforetoday Dec 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is just returning the error OK or does it need to be wrapped as an SDK status error? Errors really should never happen here as it would require the peer to send back a suitably malformed protobuf message

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@troyronda Can you confirm the desired behaviour (see comment above)?

@@ -63,7 +64,13 @@ func (e *EndorsementHandler) Handle(requestContext *RequestContext, clientContex

requestContext.Response.Responses = transactionProposalResponses
if len(transactionProposalResponses) > 0 {
requestContext.Response.Payload = transactionProposalResponses[0].ProposalResponse.GetResponse().Payload
responsePayload, err := getResultFromProposalResponse(transactionProposalResponses[0].ProposalResponse)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to fallback to transactionProposalResponses[0].ProposalResponse.GetResponse().Payload to deal with transaction error responses, or is that handled somewhere else? Passing all the tests so seems this is OK?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@troyronda Can you confirm the desired behaviour (see comment above)?

@bestbeforetoday bestbeforetoday force-pushed the tx-response branch 5 times, most recently from 6310b4e to 6b522b1 Compare December 15, 2021 19:40
This is the correct chaincode transaction response payload location. The response payload field is intended to contain metadata but the peer currently copies the transaction response payload here for convenience. This causes failures due to gRPC message size limits for large response payloads and so may be removed in the future.

Also changed a few build scripts to honour the GO_CMD environment variable.

Signed-off-by: Mark S. Lewis <mark_lewis@uk.ibm.com>
@andrew-coleman andrew-coleman merged commit 5c3f546 into hyperledger:main Feb 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants