Skip to content
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

[dotnet] Fix flaky VerifyRequestPostData test #14556

Merged

Conversation

nvborisenko
Copy link
Member

@nvborisenko nvborisenko commented Oct 3, 2024

Description

This is a potential fix of flaky VerifyRequestPostData test, which fails intermittently with error:

OpenQA.Selenium.DevTools.CommandResponseException : Network.getRequestPostData: Invalid parameters - Failed to deserialize params.requestId - BINDINGS: string value expected at position 18
   at OpenQA.Selenium.DevTools.DevToolsSession.SendCommand(String commandName, String sessionId, JsonNode commandParameters, CancellationToken cancellationToken, Nullable`1 millisecondsTimeout, Boolean throwExceptionIfResponseNotReceived)
   at OpenQA.Selenium.DevTools.DevToolsSession.SendCommand(String commandName, JsonNode commandParameters, CancellationToken cancellationToken, Nullable`1 millisecondsTimeout, Boolean throwExceptionIfResponseNotReceived)
   at OpenQA.Selenium.DevTools.DevToolsSession.SendCommand[TCommand,TCommandResponse](TCommand command, CancellationToken cancellationToken, Nullable`1 millisecondsTimeout, Boolean throwExceptionIfResponseNotReceived)
   at OpenQA.Selenium.DevTools.DevToolsNetworkTest.VerifyRequestPostData()
   at NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.GetResult()
   at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
   at NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext context)
   at NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext context)
   at NUnit.Framework.Internal.Commands.BeforeAndAfterTestCommand.<>c__DisplayClass1_0.<Execute>b__0()
   at NUnit.Framework.Internal.Commands.BeforeAndAfterTestCommand.RunTestMethodInThreadAbortSafeZone(TestExecutionContext context, Action action)

Motivation and Context

Stabilize CI.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist

  • I have read the contributing document.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

Copy link
Contributor

qodo-merge-pro bot commented Oct 3, 2024

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪
🧪 PR contains tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

Synchronization Change
The requestSync.Set() call has been moved inside the conditional block. This change may affect the test's behavior and timing.

Copy link
Contributor

qodo-merge-pro bot commented Oct 3, 2024

PR Code Suggestions ✨

Explore these optional code suggestions:

CategorySuggestion                                                                                                                                    Score
Possible issue
Add a null check for the request object before accessing its properties

Consider adding a null check for e.Request before accessing its Method property.
This can prevent potential NullReferenceExceptions if the request object is
unexpectedly null.

dotnet/test/common/DevTools/DevToolsNetworkTest.cs [386]

-if (string.Compare(e.Request.Method, "post", StringComparison.OrdinalIgnoreCase) == 0)
+if (e.Request != null && string.Compare(e.Request.Method, "post", StringComparison.OrdinalIgnoreCase) == 0)
  • Apply this suggestion
Suggestion importance[1-10]: 9

Why: Adding a null check for e.Request is a crucial improvement to prevent potential NullReferenceExceptions, which enhances the robustness and reliability of the code.

9
Best practice
Use string.Equals for case-insensitive string comparison

Consider using string.Equals with StringComparison.OrdinalIgnoreCase instead of
string.Compare. This approach is more idiomatic in C# and can improve code
readability.

dotnet/test/common/DevTools/DevToolsNetworkTest.cs [386]

-if (string.Compare(e.Request.Method, "post", StringComparison.OrdinalIgnoreCase) == 0)
+if (string.Equals(e.Request.Method, "post", StringComparison.OrdinalIgnoreCase))
  • Apply this suggestion
Suggestion importance[1-10]: 7

Why: Using string.Equals is more idiomatic and improves code readability, making it a beneficial change for maintainability and clarity.

7
Maintainability
Use a constant for the HTTP method string

Consider using a constant for the "post" string. This can improve maintainability
and reduce the risk of typos in future modifications.

dotnet/test/common/DevTools/DevToolsNetworkTest.cs [386]

-if (string.Compare(e.Request.Method, "post", StringComparison.OrdinalIgnoreCase) == 0)
+const string PostMethod = "POST";
+...
+if (string.Equals(e.Request.Method, PostMethod, StringComparison.OrdinalIgnoreCase))
Suggestion importance[1-10]: 6

Why: Defining a constant for the HTTP method string enhances maintainability and reduces the risk of errors from typos in future modifications.

6

💡 Need additional feedback ? start a PR chat

@nvborisenko
Copy link
Member Author

At least .net tests are green, thanks.

@nvborisenko nvborisenko merged commit 61d5f45 into SeleniumHQ:trunk Oct 3, 2024
8 of 10 checks passed
@nvborisenko nvborisenko deleted the fix-ci-devtools-flaky-test branch October 3, 2024 15:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant