-
Notifications
You must be signed in to change notification settings - Fork 179
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
[Access] Refactor converters into separate files #4522
Conversation
Codecov Report
@@ Coverage Diff @@
## master #4522 +/- ##
==========================================
+ Coverage 54.09% 54.44% +0.34%
==========================================
Files 563 908 +345
Lines 56220 84896 +28676
==========================================
+ Hits 30414 46218 +15804
- Misses 23459 35114 +11655
- Partials 2347 3564 +1217
Flags with carried forward coverage won't be shown. Click here to find out more.
|
engine/common/rpc/convert/events.go
Outdated
if len(p) == 0 { | ||
return p, nil | ||
} |
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.
this is the only change to the converter logic. This was needed otherwise ccf will return an eof error if the payload is empty
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 wonder if this change/check is needed.
Is a valid CcfPayload always not empty? In other words, an empty payloads CcfPayload must be invalid? In that case, then the default behavior of returning an error (EOF error) is expected, the caller is better to receive an error instead of an empty bytes. Right?
cc @fxamacker
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.
Is a valid CcfPayload always not empty?
Yes, valid CCF message is never empty.
the caller is better to receive an error instead of an empty bytes. Right?
Yes, I agree we should return error on empty data. JSON-CDC decoder currently returns error on empty data as well.
371b35f
to
6191498
Compare
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.
Thanks for the refactor
bors merge |
4522: [Access] Refactor converters into separate files r=peterargue a=peterargue The grpc converter methods were previously in one large 1200 line file, making it difficult to work with. This PR splits them up into different files per type and adds unittests validating that converting to protobuf and back results in the same object. Co-authored-by: Peter Argue <89119817+peterargue@users.noreply.github.com>
Build failed: |
bors retry |
4522: [Access] Refactor converters into separate files r=peterargue a=peterargue The grpc converter methods were previously in one large 1200 line file, making it difficult to work with. This PR splits them up into different files per type and adds unittests validating that converting to protobuf and back results in the same object. Co-authored-by: Peter Argue <89119817+peterargue@users.noreply.github.com>
Build failed: |
bors merge |
4522: [Access] Refactor converters into separate files r=peterargue a=peterargue The grpc converter methods were previously in one large 1200 line file, making it difficult to work with. This PR splits them up into different files per type and adds unittests validating that converting to protobuf and back results in the same object. Co-authored-by: Peter Argue <89119817+peterargue@users.noreply.github.com>
Build failed: |
bors merge |
The grpc converter methods were previously in one large 1200 line file, making it difficult to work with. This PR splits them up into different files per type and adds unittests validating that converting to protobuf and back results in the same object.