[Bug] with_options does not work with evalsha or eval

[mickaelmagniez]

Fred version - 10.1.0
Redis version - 8.0.1
Platform - linux
Deployment type - centralized

Describe the bug

My main goal is to having my redis call to fail as fast as possible if redis server is not available.

Using timeout with with_options works for commands like set or get, but not with evalsha

Settings timeout as in PerformanceConfig works

To Reproduce
Trying to get with with_options

Run this loop and kill the redis server halfway

#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
    set_logger();
    let options = Options {
        timeout: Some(Duration::from_secs(1)),
        fail_fast: true,
        ..Default::default()
    };
    let config = Config::from_url("redis://:gaio@localhost/")?;
    let client = Builder::from_config(config).build()?;
    client.init().await?;
    static SCRIPT: &str = "return  { KEYS[1],KEYS[2],ARGV[1],ARGV[2]}";
    for n in 1..100 {
        let results: Value = client
            .with_options(&options)
            .eval(SCRIPT.to_string(), vec!["foo", "bar"], vec![1, 2])
            .await
            .unwrap();
        info!("results: {:?}", results);
        sleep(std::time::Duration::from_millis(500));
    }
    Ok(())
}

ends with a blocking log

TRACE fred-QMQx0v4cFz: Sending command EVAL (0) to router

Adding

        .with_performance_config(|config| {
            config.default_command_timeout = Duration::from_secs(1);
        })

Fixes the issue

2025-06-17T14:18:20.012127Z TRACE fred-tbQBe7lKLS: Sending command EVAL (0) to router.    

thread 'main' panicked at src/main.rs:51:14:
called `Result::unwrap()` on an `Err` value: Error { details: "Request timed out.", kind: Timeout }

Best regards

[mickaelmagniez]

Found the issue, should be fixed with #354

Request timeout works well, but for all commands, fail_fast does not seems to always work, with no timeout it hangs, and with timeout it fails after timeout, randomly. To have fail_fast always work, i have to put a ReconnectPolicy with very low delay.

Seems the RECONNECT command does not respect the fail fast, and should wait for timeout