selenium icon indicating copy to clipboard operation
selenium copied to clipboard
verified publisher icon SeleniumHQ

[cdp][java] Allow filters to recover from failed requests in NetworkInterceptor

Open joebandenburg opened this issue 1 year ago • 6 comments

User description

Thanks for contributing to Selenium! A PR well described will help maintainers to quickly review and merge it

Before submitting your PR, please check our contributing guidelines. Avoid large PRs, help reviewers by making them as simple and short as possible.

Description

This change introduces a new exception, which is thrown through the user's filter chain when the browser fails to get a response for a request and a NetworkInterceptor is in use.

This gives the filter an opportunity to catch the exception and return a custom HTTP response.

Motivation and Context

Allow the user to intercept failed requests. See #13774 for more details.

Types of changes

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

Checklist

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

I'm not sure if this requires a documentation change but I think it would probably help and I'm happy to do that, if others agree.

Type

Enhancement, Tests

Description

  • Introduced RequestFailedException to manage scenarios where the browser fails to send a HTTP request, allowing for custom error handling.
  • Enhanced the Network.java to throw and handle RequestFailedException appropriately, giving users the ability to respond with custom HTTP responses or to let the browser handle the error.
  • Added unit tests to validate the new exception handling mechanism, ensuring that both caught and uncaught exceptions behave as expected.

Changes walkthrough

Relevant files
Enhancement
RequestFailedException.java
Add new RequestFailedException for handling failed HTTP requests

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

  • Introduced a new exception RequestFailedException to handle failed
    HTTP requests in a filter chain.
    		•  +30/-0   
    Network.java
    Enhance Network error handling with RequestFailedException

    java/src/org/openqa/selenium/devtools/idealized/Network.java

  • Modified error handling to throw RequestFailedException when a network
    request fails.
  • Added handling for RequestFailedException to allow custom user
    responses or continue normal processing.
    		•  +16/-2   
    Tests
    NetworkInterceptorTest.java
    Add tests for RequestFailedException handling in NetworkInterceptor

    java/test/org/openqa/selenium/devtools/NetworkInterceptorTest.java

  • Added tests to verify behavior when RequestFailedException is caught
    or not caught by a filter.
    		•  +18/-1   

    ✨ PR-Agent usage: Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

    joebandenburg avatar Apr 19 '24 20:04 joebandenburg

    CLA assistant check
    All committers have signed the CLA.

    CLAassistant avatar Apr 19 '24 20:04 CLAassistant

    The changes LGTM. Can you help open it up for review? Please also sign the CLA @joebandenburg. Thank you for your contribution.

    pujagani avatar Apr 23 '24 08:04 pujagani

    PR Description updated to latest commit (https://github.com/SeleniumHQ/selenium/commit/1a6c55caf0b4ddd346fef0510c9ee8977bbbca17)

    qodo-code-review[bot] avatar Apr 29 '24 15:04 qodo-code-review[bot]

    PR Review

    ⏱️ Estimated effort to review [1-5]

    3, because the PR introduces a new exception handling mechanism within the network interceptor logic, which involves understanding the flow of HTTP requests and responses, exception propagation, and the integration with existing components. The changes are moderate in size but high in complexity due to the interaction between multiple components and the need to handle asynchronous operations correctly.

    🧪 Relevant tests

    Yes

    🔍 Possible issues

    Possible Bug: The handling of RequestFailedException in the Network.java might not properly manage all edge cases, especially in highly concurrent scenarios or specific network failure modes. This needs thorough testing to ensure stability.

    Error Handling: The new exception handling introduces changes in the flow of network operations, which could lead to unintended behaviors if the exception is not caught or managed correctly in user-defined filters.

    🔒 Security concerns

    No

    ✨ Review tool usage guide:

    Overview: The review tool scans the PR code changes, and generates a PR review which includes several types of feedbacks, such as possible PR issues, security threats and relevant test in the PR. More feedbacks can be added by configuring the tool.

    The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on any PR.

    • When commenting, to edit configurations related to the review tool (pr_reviewer section), use the following template:
    /review --pr_reviewer.some_config1=... --pr_reviewer.some_config2=...

    [pr_reviewer]
some_config1=...
some_config2=...

    See the review usage page for a comprehensive guide on using this tool.

    qodo-code-review[bot] avatar Apr 29 '24 15:04 qodo-code-review[bot]

    PR Code Suggestions

    CategorySuggestions                                                                                                                                                       
    Enhancement
    Add logging when a null future is encountered to aid in debugging.

    It's good practice to log the exception or provide some feedback when a null future is
    encountered. This helps in debugging and understanding why no response was pending for a
    given request ID.

    java/src/org/openqa/selenium/devtools/idealized/Network.java [208-209]

     if (future == null) {
+  LOG.warning("No pending response for request ID: " + id);
   devTools.send(continueWithoutModification(pausedRequest));
 }
    Log RequestFailedException to provide more context on network errors.

    When catching RequestFailedException, it might be beneficial to log this specific
    exception to help with monitoring and troubleshooting specific failures related to network
    requests.

    java/src/org/openqa/selenium/devtools/idealized/Network.java [252-255]

     if (e.getCause() instanceof RequestFailedException) {
+  LOG.log(Level.SEVERE, "Request failed due to network error", e);
   throw (RequestFailedException) e.getCause();
 }
    Log unhandled RequestFailedException to improve error tracking.

    Consider adding a specific log message or handling mechanism when RequestFailedException
    is not caught by the user's filter. This could help in identifying unhandled network
    errors more clearly.

    java/src/org/openqa/selenium/devtools/idealized/Network.java [275-277]

     } catch (RequestFailedException e) {
+  LOG.warning("Unhandled RequestFailedException, continuing without modification.");
   devTools.send(continueWithoutModification(pausedRequest));
 }
    Add a general exception handler to catch and log unexpected exceptions.

    To ensure that all exceptions are properly handled, consider adding a general catch block
    for exceptions that might not be explicitly caught by the existing code.

    java/src/org/openqa/selenium/devtools/idealized/Network.java [278-280]

    +} catch (Exception e) {
+  LOG.log(Level.SEVERE, "An unexpected error occurred during request processing", e);
+  throw new RuntimeException(e);
 } catch (TimeoutException e) {
   if (fetchEnabled.get()) {
     throw e;
   }
    Best practice
    Safely cast exceptions to their specific types before rethrowing to avoid ClassCastException.

    To improve the robustness of the error handling, consider verifying the type of the
    exception before casting and rethrowing it.

    java/src/org/openqa/selenium/devtools/idealized/Network.java [252-255]

     if (e.getCause() instanceof RequestFailedException) {
-  throw (RequestFailedException) e.getCause();
+  RequestFailedException rfe = (RequestFailedException) e.getCause();
+  throw rfe;
 }
    ✨ Improve tool usage guide:

    Overview: The improve tool scans the PR code changes, and automatically generates suggestions for improving the PR code. The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on a PR.

    • When commenting, to edit configurations related to the improve tool (pr_code_suggestions section), use the following template:
    /improve --pr_code_suggestions.some_config1=... --pr_code_suggestions.some_config2=...

    [pr_code_suggestions]
some_config1=...
some_config2=...

    See the improve usage page for a comprehensive guide on using this tool.

    qodo-code-review[bot] avatar Apr 29 '24 15:04 qodo-code-review[bot]

    I'm not sure whether this constitutes a breaking API change. Existing filters may already catch WebDriverException, RuntimeException or Exception. If that's the case, the behaviour reverts to how it was prior to #13836 landing. So looking at the combination of this change and #13836, I don't think it's a breaking change.

    joebandenburg avatar Apr 29 '24 15:04 joebandenburg