-
Notifications
You must be signed in to change notification settings - Fork 610
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
Fixes issue where a CE response is truncated #6758
Conversation
Codecov ReportBase: 80.47% // Head: 80.47% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #6758 +/- ##
==========================================
- Coverage 80.47% 80.47% -0.01%
==========================================
Files 236 236
Lines 12164 12162 -2
==========================================
- Hits 9789 9787 -2
Misses 1888 1888
Partials 487 487
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to include an e2e broker conformance test that could be used to test the Kafka and RabbitMQ implementations as well.
execInfo.ResponseBody = []byte(fmt.Sprintf("dispatch error: %s", err.Error())) | ||
} else { | ||
execInfo.ResponseBody = body[:readLen] | ||
execInfo.ResponseBody = body.Bytes() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you still want to truncate the payload here in error cases?
(I suspect the right thing to do may actually be to truncate the overall message, preferring to cut payload over other attributes.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't check if the response is a cloud event in error cases. The payload gets truncated in a later step by a transformer and then put in as a cloud event extension on the original message. It's then sent to the dead letter. So I think the truncation still happens, it's just no longer part of the executeRequest
I'll double check the above and add a conformance test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll double check the above and add a conformance test
@gab-satchi Did you add some conformance test for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a different test, added as e2e, for a "large" incoming request: https://github.com/knative/eventing/pull/6666/files @gab-satchi wanna add a similar test for the respone? And looks like we should backport this to 1.8+ (given the referenced PR landed after 1.7 release) |
Thanks @matzew, added a similar test |
/retest |
I'd like to get this, eventually, backported to 1.9 and 1.8 as well, @gab-satchi thanks for looking at this /lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gab-satchi, matzew The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/cherry-pick release-1.9 |
@matzew: once the present PR merges, I will cherry-pick it on top of release-1.9 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/cherry-pick release-1.8 |
@matzew: once the present PR merges, I will cherry-pick it on top of release-1.8 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/unhold |
@matzew: new pull request created: #6781 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@matzew: new pull request created: #6782 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
… (knative#6783) cherry-pick of knative#6758 ```release-note 🐛 Fixes an issue where a Cloud Event in a response from a sink was truncated to 1024 bytes ```
… (knative#6783) (#141) cherry-pick of knative#6758 ```release-note 🐛 Fixes an issue where a Cloud Event in a response from a sink was truncated to 1024 bytes ``` Co-authored-by: Gab Satchi <[email protected]>
## Proposed Changes - 🐛 Fixes an issue where a Cloud Event in a response from a sink was truncated to 1024 bytes ### Pre-review Checklist <!-- If these boxes are not checked, you will be asked to complete these requirements or explain why they do not apply to your PR. --> - [x] **At least 80% unit test coverage** - [x] **E2E tests** for any new behavior - [x] **Docs PR** for any user-facing impact - [x] **Spec PR** for any new API feature - [x] **Conformance test** for any change to the spec **Release Note** ```release-note 🐛 Fixes an issue where a Cloud Event in a response from a sink was truncated to 1024 bytes ``` Before the changes in knative#6521, the response was being truncated when an error occurred. That felt wrong as well, so with these changes, response body isn't truncated regardless of status.
Proposed Changes
Pre-review Checklist
Release Note
Before the changes in #6521, the response was being truncated when an error occurred. That felt wrong as well, so with these changes, response body isn't truncated regardless of status.