First, it adds a .clear_request_by_id(request_id) method to the storage classes, which allows deleting/clearing of a single request from the storage rather than deleting/clearing all at once. This method is available as .delete_request(request_id) in the InspectRequestsMixin (and thus the webdriver).
Personally, I believe a more elegant solution would be changing InspectRequestsMixin.requests to return a custom class implementing __delitem__, which would allow us to use del driver.requests[request_id] instead, but I am not sure if this would break compatibility for some users.
Secondly, it exposes the check_response parameter of the .find() method of the storage as InspectRequestMixin.wait_for_requests(..., check_response=False), allowing users to wait for requests until a response is available.
Additionally, test cases and documentation updates for these changes have been included.
Hi,
this PR does two things:
First, it adds a
.clear_request_by_id(request_id)method to the storage classes, which allows deleting/clearing of a single request from the storage rather than deleting/clearing all at once. This method is available as.delete_request(request_id)in theInspectRequestsMixin(and thus the webdriver).Personally, I believe a more elegant solution would be changing
InspectRequestsMixin.requeststo return a custom class implementing__delitem__, which would allow us to usedel driver.requests[request_id]instead, but I am not sure if this would break compatibility for some users.Secondly, it exposes the
check_responseparameter of the.find()method of the storage asInspectRequestMixin.wait_for_requests(..., check_response=False), allowing users to wait for requests until a response is available.Additionally, test cases and documentation updates for these changes have been included.