Correct sampling interval values

[priyaranjannanda]

Changes for

• setting sampling interval value for each port execution
• While reading the value from interval, the mutiplication logic is corrected. sampleing interval value is returned in nanosecond.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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 refactors the handling of the samplingInterval in the zrp_low_power_mode_test to ensure accurate and localized interval settings for each port's execution. It corrects a potential misinterpretation of GNMI-provided sampling interval values by removing an erroneous unit conversion and enhances test coverage by conditionally adding a transceiver description stream.

Highlights

• Sampling Interval Scope: The samplingInterval variable was moved from a global declaration to a local scope within the TestLowPowerMode function, ensuring that each test execution correctly initializes and uses its own interval.
• Sampling Interval Calculation Correction: The logic for reading the samplingInterval from GNMI was corrected by removing an erroneous multiplication by time.Second, as the GNMI Interval().State() is now assumed to return a value directly interpretable as time.Duration (likely in nanoseconds).
• Transceiver Description Stream: A new stream for transceiver description was conditionally added to the test, improving test coverage for transceiver details when not skipped by deviations.

Changelog

• feature/platform/transceiver/tests/zrp_low_power_mode_test/zrp_low_power_mode_test.go
  • Removed the global declaration of samplingInterval.
  • Declared samplingInterval locally within the TestLowPowerMode function.
  • Corrected the retrieval of samplingInterval from GNMI by removing the * time.Second multiplication.
  • Added conditional streaming for transceiver description.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize 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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. 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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[OpenConfigBot]

Pull Request Functional Test Report for #5192 / 27f1e2a

Virtual Devices

Device	Test	Test Documentation	Job	Raw Log
Arista cEOS		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Cisco 8000E		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Cisco XRd		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Juniper ncPTX		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Nokia SR Linux		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Openconfig Lemming		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.

Hardware Devices

Device	Test	Test Documentation	Raw Log
Arista 7808		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Cisco 8808		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Juniper PTX10008		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Nokia 7250 IXR-10e		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.

Help

[gemini-code-assist]

Code Review

My main feedback is to adjust the scope of the samplingInterval variable to ensure that each subtest for a port runs independently without being affected by the state of the previous one. This will improve test robustness and prevent potential flakes.

[gemini-code-assist]

To ensure that each port's subtest runs with a clean state and is not affected by the previous run, the samplingInterval variable should be initialized within the scope of the t.Run block. Currently, it's defined outside the loop and modified within each subtest, which means the value from the port1 test will carry over to the port2 test. This could lead to unexpected behavior if the sampling intervals differ between ports.

Suggested change

	samplingInterval := 10 * time.Second
	for _, port := range []string{"port1", "port2"} {
	t.Run(fmt.Sprintf("Port:%s", port), func(t *testing.T) {
	for _, port := range []string{"port1", "port2"} {
	t.Run(fmt.Sprintf("Port:%s", port), func(t *testing.T) {
	samplingInterval := 10 * time.Second