Increase payload size and adjust gRPC message size limit for Acctz-4.2#5503
Increase payload size and adjust gRPC message size limit for Acctz-4.2#5503youssefyamoutyy wants to merge 2 commits into
Conversation
…yload truncation test
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a gRPC message size limit error encountered during the Acctz record subscription test. By increasing the test payload size and adjusting the gRPC receive message limit, the test is now able to successfully process the oversized, truncated record responses as intended. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
Pull Request Functional Test Report for #5503 / e66c3abVirtual Devices
Hardware Devices
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request increases the loop limit for generating network instances to 150 to create a larger payload and configures the gRPC subscription with a larger maximum message receive size. A review comment points out that increasing the loop limit causes the generated IP addresses to fall into public IP ranges, violating the repository's network assignment guidelines.
| ocRoot := &oc.Root{} | ||
|
|
||
| for i := 0; i < 50; i++ { | ||
| for i := 0; i < 150; i++ { |
There was a problem hiding this comment.
By increasing the loop limit to 150, the generated next-hop IP addresses 192.%d.2.1 (on line 53) will fall into ranges like 192.150.2.1, which are public IP addresses and violate the repository's network assignment guidelines. According to the Repository Style Guide (Section 1, Network Assignments): Use RFC 5737 blocks (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) or 100.64.0.0/10, 198.18.0.0/15. Please update the IP generation logic to use a compliant range, such as 198.18.i.1 (since 198.18.0.0/15 can easily accommodate 150 subnets).
References
- IPv4: Use RFC 5737 blocks (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) or 100.64.0.0/10, 198.18.0.0/15. (link)
4 participants
The PR incorporates PR 5022 fix by increasing the test payload size and setting a larger MaxCallRecvMsgSize for the Accountz record subscription. That lets the test receive the oversized, and later truncated record response.
grpc: received message larger than maxwas seen.Adding closed PR as reference: #5022