Replies: 1 comment
-
I found that the driver.gui_click_x_y(x, y) function is responsible for the problem. I left prints inside; it can be called at the same time.
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello,
I've developed a FastAPI application that instantiates about ten instances at startup using the ThreadPoolExecutor :
Each instance has a status attribute (busy, free).
I created a /crawl route that receives a URL with a potential action scenario (Cloudflare form clicks, field completions, waiting for an HTML block to appear or disappear, etc.). The route selects a free instance, locks it, performs the crawl and possibly some associated actions, then returns the HTML content of the page, and finally unlocks the instance.
However, I've noticed that sometimes, on certain requests, the process hangs somewhere in the actions, and FastAPI never responds.
The browser instance doesn't crash, and stays open. It just stays in busy status because the process doesn't reach the instance unlock. I had to implement an unfreeze mechanism, which isn't clean at all, and doesn't solve the problem of unresponsive requests.
Are there any precautions to take? Are some CDP functions thread-safe?
I've found that the problem is much more common starting at 5 or 6 instances; below this threshold, the problem is very rare. Also, queries that don't perform any actions don't seem to be affected, which leads me to believe the problem lies in my use of functions (assert_element_present, find_element, get_gui_element_rect, gui_click_x_y, send_keys, click, etc.).
If you have any ideas, I'd love to hear them :)
Beta Was this translation helpful? Give feedback.
All reactions