-
Notifications
You must be signed in to change notification settings - Fork 4.6k
alts: move ParseFramedMsg out of common #8511
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
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #8511 +/- ##
==========================================
- Coverage 82.40% 81.85% -0.56%
==========================================
Files 414 413 -1
Lines 40531 40520 -11
==========================================
- Hits 33399 33167 -232
- Misses 5770 5982 +212
- Partials 1362 1371 +9
🚀 New features to boost your workflow:
|
@kevinGC, it would be great if you could rebase this branch off of master so both PRs can be merged independently. We shouldn't need Go 1.24 for the changes in this PR. |
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, with request to remove the Go 1.24 changes. Adding a reviewer from the security team.
I think the easiest way for reviewers to diff is to just get the prior PRs merged and then this will diff nicely against master The other option is to make a PR on your fork against the other PR branch if you want us to see the diff right now, then eventually open a PR later |
// Frame is not complete yet. | ||
return nil, nil | ||
} | ||
p.nextFrame = b[MsgLenFieldSize+length:] |
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.
At a glance I personally prefer the previous style of returning nextFrame and not modifying state in this method, I think it makes it easier to follow and test. Do we have a compelling reason to swap it to 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'm happy to leave as-is or revert back to the old version. It just seemed odd to have a function in common.go
that's only called in 1 place and always called s.t. it modifies the same bit of struct state.
Happy with whatever the gRPC team wants -- this was more of an implementation detail on the way to my other changes.
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.
Deferring to the @gtcooke94 since the security team owns this package. Closing the PR.
It's only called in one place, and is effectively a method on conn. Part of grpc#8510.
dc8a0ca
to
9efdb0d
Compare
Rebased. Looks like there're differing opinions on whether this is change is worth making -- I'm cool with keeping or dropping it. |
It's only called in one place, and is effectively a method on conn.
Part of #8510.
Note that this PR includes #8509. GitHub doesn't support proper commit chains / stacked PRs, so I'm doing this in several PRs with some (annoyingly) redundant commits. Let me know if this isn't a good workflow for you and I'll change things up.
RELEASE NOTES: N/A