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

Allow sending DevTools command with custom timeout. #15059

Open
wants to merge 2 commits into
base: trunk
Choose a base branch
from

Conversation

dennisoelkers
Copy link
Contributor

@dennisoelkers dennisoelkers commented Jan 10, 2025

Description

This PR is introducing an additional method (DevTools#sendWithTimeout) that allows consumers to send a DevTools command with a custom timeout instead of the hardcoded one.

Motivation and Context

Some commands send oder CDP can take longer than the hardcoded timeout, e.g. printing a page to PDF. This might happen due to excessive work in the controller browser or during serialization/transmission. For cases like this, DevTools#sendWithTimeout can be used to use a higher timeout for these exceptional cases.

Fixes #14912.

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.

PR Type

Enhancement


Description

  • Introduced sendWithTimeout method for custom timeout in DevTools commands.

  • Refactored send method to utilize sendWithTimeout internally.

  • Improved flexibility for handling long-running DevTools commands.


Changes walkthrough 📝

Relevant files
Enhancement
DevTools.java
Add `sendWithTimeout` method for configurable timeouts     

java/src/org/openqa/selenium/devtools/DevTools.java

  • Added sendWithTimeout method for sending commands with a custom
    timeout.
  • Refactored send method to delegate to sendWithTimeout.
  • Ensured non-null validation for commands in sendWithTimeout.
  • +6/-2     

    💡 PR-Agent usage: Comment /help "your question" on any pull request to receive relevant information

    Copy link
    Contributor

    PR Reviewer Guide 🔍

    Here are some key observations to aid the review process:

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

    Parameter Validation

    The timeout parameter in sendWithTimeout() should be validated to ensure it's not null or negative to prevent potential runtime issues

    public <X> X sendWithTimeout(Command<X> command, Duration timeout) {
        Require.nonNull("Command to send", command);
        return connection.sendAndWait(cdpSession, command, timeout);
    }

    Copy link
    Contributor

    qodo-merge-pro bot commented Jan 10, 2025

    PR Code Suggestions ✨

    Explore these optional code suggestions:

    CategorySuggestion                                                                                                                                    Score
    Possible issue
    Add session state validation to prevent null pointer exceptions

    Add validation to ensure cdpSession is not null before sending commands to prevent
    NullPointerException.

    java/src/org/openqa/selenium/devtools/DevTools.java [72-75]

     public <X> X sendWithTimeout(Command<X> command, Duration timeout) {
         Require.nonNull("Command to send", command);
    +    Require.state(cdpSession != null, "CDP session is not active");
         return connection.sendAndWait(cdpSession, command, timeout);
     }
    • Apply this suggestion
    Suggestion importance[1-10]: 9

    Why: This suggestion addresses a critical potential null pointer vulnerability by validating the CDP session state before execution. Given that cdpSession is nullable (as seen in disconnectSession), this validation is essential for preventing runtime crashes.

    9
    Add input validation for timeout parameter to prevent invalid duration values

    Add validation to ensure the timeout parameter is positive and non-null to prevent
    potential issues with negative or null timeouts.

    java/src/org/openqa/selenium/devtools/DevTools.java [72-75]

     public <X> X sendWithTimeout(Command<X> command, Duration timeout) {
         Require.nonNull("Command to send", command);
    +    Require.nonNull("Timeout duration", timeout);
    +    Require.positive("Timeout duration", timeout.toMillis());
         return connection.sendAndWait(cdpSession, command, timeout);
     }
    • Apply this suggestion
    Suggestion importance[1-10]: 8

    Why: Adding validation for the timeout parameter is crucial for preventing runtime errors and ensuring proper function behavior. The suggestion adds comprehensive checks for null and negative values, which are essential for a parameter that controls execution timing.

    8

    return sendWithTimeout(command, this.timeout);
    }

    public <X> X sendWithTimeout(Command<X> command, Duration timeout) {
    Copy link
    Member

    Choose a reason for hiding this comment

    The reason will be displayed to describe this comment to others. Learn more.

    Let's just name it send.

    @shbenzer
    Copy link
    Contributor

    @diemol do we need to add a test for this?

    @diemol
    Copy link
    Member

    diemol commented Jan 12, 2025

    I don't see the need for it. What do you think?

    @shbenzer
    Copy link
    Contributor

    I don't see the need for it. What do you think?

    After taking another look, I don't think so. I didn't realize sendWithTimeout() was just a wrapper for sendAndWait()

    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.

    [🐛 Bug]: DevTools timeout is hardcoded and not sufficient for some commands
    3 participants