Idiomatically await elements of a Vec about thirtyfour

[stevepryde]

Btw there isn't a lot of point in doing the selenium calls in parallel because they will be executed sequentially anyway. This is a design decision to make browser testing more predictable but I could see use cases where parallelism might be beneficial, such as this one.

For now you can simplify by doing each request in series and awaiting each time (without join_all()). Otherwise your solution seems to be on the right track. It doesn't look so ugly to me.
Do you actually want the error ones in the list? It seems to me that you probably want to filter by result and collect all the Ok vs Err ones in different vecs.

[stevepryde]

The mutex is only per webdriver instance so there is no reason why separate webdriver instances could not execute requests in parallel.

Have a read of the Tokio join! call for more details.

[bcpeinhardt]

Current ugly solution

let mut future_web_driver_result_option_strings = Vec::new();
            for link in new_order_links.iter() {
                future_web_driver_result_option_strings.push(link.get_attribute("href"));
            }
            let web_driver_result_option_strings =
                futures::future::join_all(future_web_driver_result_option_strings).await;

            let urls = web_driver_result_option_strings
                .into_iter()
                .map(|wdros| {
                    if let Ok(Some(url)) = wdros {
                        return url;
                    }

                    "error".to_string()
                })
                .filter(|url| !enforced_orders.contains(&url))
                .collect::<Vec<String>>();

[bcpeinhardt]

That's probably what I'll end up doing with the errors. I was just quickly trying to set up a scenario where these urls are sent via a multi producer multi consumer channel to other WebDrivers for processing as part of some discovery I'm doing. The enforced_orders vec is instantiated with that error string and only serves to prevent me from sending duplicate urls through the channel.

The links are links to order forms in a queue of orders to be processed, so even if there's an error scraping the link or it's href I'll want to retry until the url is successfully retrieved or the order is no longer in the queue, as the success value of following the link doesn't effect whether I should attempt automation on that order. Not that I bothered sharing any of that context before xD

[bcpeinhardt]

Hello,
I just wanted to follow up on the discussion of how Selenium handles these calls. I totally see why the individual selenium calls from a single driver ought to be in order. If I connect to a standalone selenium server with /wd/hub and then connect two drivers to it, will calls made by each of those drivers come back asynchronously or in order? I don't really want to mess with docker and/or VMs and whatnot because I'm just running on my local machine, but I really do need the async behavior (I don't want one driver doing nothing because another driver is waiting on the server). Right now I'm spinning up geckodrivers individually on open ports and connecting directly to guarantee async behavior, but this is definitely a hassle.

[stevepryde]

https://rust-lang.github.io/async-book/06_multiple_futures/01_chapter.html

[bcpeinhardt]

This makes my life so much easier xD Thank you!