alts: move ParseFramedMsg out of common - #8511
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. |
arjan-bal
left a comment
arjan-bal
left a comment
There was a problem hiding this comment.
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.
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.
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.
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. |
3 participants
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