feat: add retry mechanism

[Salka1988]

Closes #1020.

This code is an implementation of a retry mechanism that allows a function to be retried a certain number of times with a specified interval between attempts.

RetryConfig: This is a configuration struct that holds the retry configuration. It contains the following fields:

• max_attempts: The maximum number of times the action should be retried.
• interval: Determines the backoff strategy and timing to be used during retry attempts. It allows you to configure how much time a system should wait before retrying an action after a failure.

retry<Fut, T, ShouldRetry>: This is the main function responsible for implementing the retry logic.

This function takes several parameters:

• action: A closure that performs the action you want to retry. It returns a Future of the result.
• retry_config: A reference to a RetryConfig struct that specifies the retry behavior.
• should_retry: A closure that takes a reference to the result of the action and returns a boolean indicating whether the action should be retried based on the result.

Aditional Work:
I've separated sending a transaction from getting back its value:

  let response = contract_methods.get(1, 2).submit().await?;
  let value = response.response().await?;

Added RetryableClient a wrapper around the FuelClient that provides a convenient way to interact with a remote service. It also enables automatic retry functionality in scenarios where network issues may occur.

#[derive(Debug, Clone)]
pub(crate) struct RetryableClient {
    client: FuelClient,
    url: String,
    retry_config: RetryConfig,
}

Checklist

• I have linked to any relevant issues.
• I have updated the documentation.
• I have added necessary labels.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[Br1ght0ne]

Great UX and overall approach! I have a small consideration regarding the logic itself.

When designing a retry mechanism for anything with a notion of “network call” in some way, I like implementing a delay to allow the network to self-regulate its throughput when congested and often requiring less attempts overall.

I usually go for exponential backoff - delays start off small and ramp up steadily. There are crates like backon and backoff with full support of sync/async functions.

Extra considerations:

• what are acceptable minimum/maximum delays for our use case?

Alternatives:

• hand-roll our own delayed retrying (only if adding a dependency is a problem)
• skip having delays altogether (I hereby request your comments on it)

[Salka1988]

Great UX and overall approach! I have a small consideration regarding the logic itself.

When designing a retry mechanism for anything with a notion of “network call” in some way, I like implementing a delay to allow the network to self-regulate its throughput when congested and often requiring less attempts overall.

I usually go for exponential backoff - delays start off small and ramp up steadily. There are crates like backon and backoff with full support of sync/async functions.

Extra considerations:

• what are acceptable minimum/maximum delays for our use case?

Alternatives:

• hand-roll our own delayed retrying (only if adding a dependency is a problem)
• skip having delays altogether (I hereby request your comments on it)

I will use one of the crates you recommended or similar. If that's a problem, I'll implement `exponential backoff'.
Or maybe simple:

    let mut delay = Duration::from_secs(1);

    for _ in 0..retries {
        sleep(delay).await;
        delay *= 2; 
    } 

will be enough.

[segfault-magnet]

Not all errors benefit from retrying. Usually, you want to wait out a transient error (network or some other kind) and not actually offer a fully-fledged retry mechanism to the user especially when retrying again so fast.

For example, if the tx is out of gas it will be reverted and you'll retry again most probably changing nothing (and more importantly - wasting gas).

[Salka1988]

Not all errors benefit from retrying. Usually, you want to wait out a transient error (network or some other kind) and not actually offer a fully-fledged retry mechanism to the user especially when retrying again so fast.

For example, if the tx is out of gas it will be reverted and you'll retry again most probably changing nothing (and more importantly - wasting gas).

You are right, I understand you but will we waste gas if we fail?

[segfault-magnet]

Not all errors benefit from retrying. Usually, you want to wait out a transient error (network or some other kind) and not actually offer a fully-fledged retry mechanism to the user especially when retrying again so fast.
For example, if the tx is out of gas it will be reverted and you'll retry again most probably changing nothing (and more importantly - wasting gas).

You are right, I understand you but will we waste gas if we fail?

Yep. You lose the gas used to execute the contract up until the point of reverting. The rest will be refunded if you provided an adequate change output.

[segfault-magnet]

Not all errors benefit from retrying. Usually, you want to wait out a transient error (network or some other kind) and not actually offer a fully-fledged retry mechanism to the user especially when retrying again so fast.
For example, if the tx is out of gas it will be reverted and you'll retry again most probably changing nothing (and more importantly - wasting gas).

You are right, I understand you but will we waste gas if we fail?

Yep. You lose the gas used to execute the contract up until the point of reverting. The rest will be refunded if you provided an adequate change output.

Taking a different approach

[Br1ght0ne]

Thanks for your consideration @Salka1988! I agree with @segfault-magnet - saving on gas is important, and a proper max_attempts should be set to avoid excessive retrying. I dismissed my blocking review, and will approve whatever logic we agree on (if the code is correct 😉)

[Salka1988]

Not all errors benefit from retrying. Usually, you want to wait out a transient error (network or some other kind) and not actually offer a fully-fledged retry mechanism to the user especially when retrying again so fast.
For example, if the tx is out of gas it will be reverted and you'll retry again most probably changing nothing (and more importantly - wasting gas).

You are right, I understand you but will we waste gas if we fail?

Yep. You lose the gas used to execute the contract up until the point of reverting. The rest will be refunded if you provided an adequate change output.

Yea! I forgot about simulate()

[segfault-magnet]

Reviewed and gave feedback live with @Salka1988 .

[Salka1988]

Reviewed and gave feedback live with @Salka1988 .

@segfault-magnet creativity and expertise truly elevated the outcome. Thanx!

[hal3e]

Awesome work!