Stratégie de nouvelle tentative

C++

Par défaut, les opérations autorisent les nouvelles tentatives pour les codes d'erreur HTTP suivants, ainsi que pour les erreurs de socket indiquant que la connexion a été perdue ou n'a jamais été établie.

• 408 Request Timeout
• 429 Too Many Requests
• 500 Internal Server Error
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout

Tous les paramètres de la bibliothèque C++ concernant l'intervalle exponentiel entre les tentatives et les nouvelles tentatives sont configurables. Si les algorithmes mis en œuvre dans la bibliothèque ne répondent pas à vos besoins, vous pouvez fournir un code personnalisé pour mettre en œuvre vos propres stratégies.

Par défaut, la bibliothèque C++ relance toutes les opérations comportant des erreurs récupérables, même celles qui ne sont jamais idempotentes et sont susceptibles de supprimer ou créer plusieurs ressources lorsqu'elles sont répétées plusieurs fois avec succès. Pour ne relancer que les opérations idempotentes, utilisez la classe google::cloud::storage::StrictIdempotencyPolicy.

C#

Par défaut, la bibliothèque cliente C# utilise un intervalle exponentiel entre les tentatives.

Go

Par défaut, les opérations sont compatibles avec les nouvelles tentatives pour les erreurs suivantes :

• Erreurs de connexion :
  • io.ErrUnexpectedEOF : cette erreur peut survenir en raison de problèmes réseau temporaires.
  • url.Error contenant connection refused : cette erreur peut survenir en raison de problèmes réseau temporaires.
  • url.Error contenant connection reset by peer : cette erreur signifie que Google Cloud a réinitialisé la connexion.
  • net.ErrClosed : cette erreur signifie que Google Cloud a fermé la connexion.
• Codes HTTP :
  • 408 Request Timeout
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout
• Erreurs qui mettent en œuvre l'interface Temporary() et renvoient la valeur err.Temporary() == true
• Toutes les erreurs ci-dessus qui ont été encapsulées à l'aide de l'encapsulation d'erreur Go 1.13

Tous les paramètres de la bibliothèque Go concernant l'intervalle exponentiel entre les tentatives sont configurables. Par défaut, les opérations en Go utilisent les paramètres suivants d'intervalle exponentiel entre les tentatives (les valeurs par défaut proviennent de gax) :

La répétition des tentatives se poursuit indéfiniment, sauf si le contexte de contrôle est annulé, si le client est fermé ou si une erreur non temporaire est reçue. Pour empêcher la répétition des tentatives, utilisez des délais d'expiration de contexte ou une annulation. La seule exception à ce comportement se produit lors de l'exécution d'importations avec reprise à l'aide de Writer, où les données sont suffisamment volumineuses pour nécessiter plusieurs requêtes. Dans ce scénario, chaque fragment expire et cesse d'effectuer de nouvelles tentatives après 32 secondes par défaut. Vous pouvez ajuster le délai avant expiration par défaut en modifiant Writer.ChunkRetryDeadline.

Il existe un sous-ensemble d'opérations Go idempotentes sous conditions (sous conditions, elles peuvent être relancées en toute sécurité). Ces opérations n'effectuent de nouvelles tentatives que si elles répondent à des conditions spécifiques :

• GenerationMatch ou Generation

  • Tentatives relancées en toute sécurité si une condition préalable GenerationMatch a été appliquée à l'appel ou si ObjectHandle.Generation a été défini.

• MetagenerationMatch

  • Tentatives relancées en toute sécurité si une condition préalable MetagenerationMatch a été appliquée à l'appel.

• Etag

  • Vous pouvez effectuer de nouvelles tentatives si la méthode insère un etag dans le corps de la requête JSON. Utilisé uniquement dans HMACKeyHandle.Update lorsque HmacKeyMetadata.Etag a été défini.

RetryPolicy est défini par défaut sur RetryPolicy.RetryIdempotent. Consultez la section Personnaliser les nouvelles tentatives pour obtenir des exemples montrant comment modifier le comportement des nouvelles tentatives par défaut.

Java

Par défaut, les opérations sont compatibles avec les nouvelles tentatives pour les erreurs suivantes :

• Erreurs de connexion :
  • Connection reset by peer : cette erreur signifie que Google Cloud a réinitialisé la connexion.
  • Unexpected connection closure : cette erreur signifie que Google Cloud a fermé la connexion.
• Codes HTTP :
  • 408 Request Timeout
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

Tous les paramètres de la bibliothèque Java concernant l'intervalle exponentiel entre les tentatives sont configurables. Par défaut, les opérations via Java utilisent les paramètres suivants pour un intervalle exponentiel entre les tentatives :

Pour en savoir plus sur les paramètres, consultez la documentation de référence Java pour RetrySettings.Builder et HttpTransportOptions.Builder.

Il existe un sous-ensemble d'opérations Java idempotentes sous conditions (sous conditions, elles peuvent être relancées en toute sécurité). Ces opérations n'effectuent de nouvelles tentatives que si elles incluent des arguments spécifiques :

• ifGenerationMatch ou generation

  • Vous pouvez effectuer de nouvelles tentatives si ifGenerationMatch ou generation a été transmis en tant qu'option à la méthode.

• ifMetagenerationMatch

  • Peut être relancée en toute sécurité si le paramètre ifMetagenerationMatch a été transmis en tant qu'option.

StorageOptions.setStorageRetryStrategy est défini par défaut sur StorageRetryStrategy#getDefaultStorageRetryStrategy. Consultez la section Personnaliser les nouvelles tentatives pour obtenir des exemples montrant comment modifier le comportement des nouvelles tentatives par défaut.

Node.js

Par défaut, les opérations sont compatibles avec les nouvelles tentatives pour les codes d'erreur suivants :

• Erreurs de connexion :
  • EAI_again : erreur de résolution DNS. Pour en savoir plus, reportez-vous à la documentation sur le paramètre getaddrinfo.
  • Connection reset by peer : cette erreur signifie que Google Cloud a réinitialisé la connexion.
  • Unexpected connection closure : cette erreur signifie que Google Cloud a fermé la connexion.
• Codes HTTP :
  • 408 Request Timeout
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

Tous les paramètres de la bibliothèque Node.js concernant l'intervalle exponentiel entre les tentatives sont configurables. Par défaut, les opérations via Node.js utilisent les paramètres suivants pour un intervalle exponentiel entre les tentatives :

Il existe un sous-ensemble d'opérations Node.js idempotentes sous conditions (sous conditions, elles peuvent être relancées en toute sécurité). Ces opérations n'effectuent de nouvelles tentatives que si elles incluent des arguments spécifiques :

• ifGenerationMatch ou generation

  • Vous pouvez effectuer de nouvelles tentatives si ifGenerationMatch ou generation a été transmis en tant qu'option à la méthode. Les méthodes n'acceptent souvent que l'un de ces deux paramètres.

• ifMetagenerationMatch

  • Peut être relancée en toute sécurité si le paramètre ifMetagenerationMatch a été transmis en tant qu'option.

retryOptions.idempotencyStrategy est défini par défaut sur IdempotencyStrategy.RetryConditional. Consultez la section Personnaliser les nouvelles tentatives pour obtenir des exemples montrant comment modifier le comportement des nouvelles tentatives par défaut.

PHP

Par défaut, la bibliothèque cliente PHP utilise l'intervalle exponentiel entre les tentatives.

Python

Par défaut, les opérations sont compatibles avec les nouvelles tentatives pour les codes d'erreur suivants :

• Erreurs de connexion :
  • requests.exceptions.ConnectionError
  • requests.exceptions.ChunkedEncodingError (uniquement pour les opérations de récupération ou d'envoi de données de charge utile à des objets, telles que les importations et les téléchargements)
  • ConnectionError
• Codes HTTP :
  • 408 Request Timeout
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

Les opérations via Python utilisent les paramètres par défaut suivants pour l'intervalle exponentiel entre les tentatives :

Il existe un sous-ensemble d'opérations Python idempotentes sous conditions (sous conditions, elles peuvent être relancées en toute sécurité). Ces opérations n'effectuent de nouvelles tentatives que si une condition est satisfaite :

• DEFAULT_RETRY_IF_GENERATION_SPECIFIED

  • Vous pouvez effectuer de nouvelles tentatives si generation ou if_generation_match a été transmis en tant qu'argument à la méthode. Les méthodes n'acceptent souvent que l'un de ces deux paramètres.

• DEFAULT_RETRY_IF_METAGENERATION_SPECIFIED

  • Vous pouvez effectuer de nouvelles tentatives si if_metageneration_match a été transmis en tant qu'argument à la méthode.

• DEFAULT_RETRY_IF_ETAG_IN_JSON

  • Vous pouvez effectuer de nouvelles tentatives si la méthode insère un etag dans le corps de la requête JSON. Pour HMACKeyMetadata.update(), cela signifie que l'eTag doit être défini sur l'objet HMACKeyMetadata lui-même. Pour la méthode set_iam_policy() sur d'autres classes, cela signifie que l'eTag doit être défini dans l'argument "policy" transmis à la méthode.

Ruby

Par défaut, les opérations sont compatibles avec les nouvelles tentatives pour les codes d'erreur suivants :

• Erreurs de connexion :
  • SocketError
  • HTTPClient::TimeoutError
  • Errno::ECONNREFUSED
  • HTTPClient::KeepAliveDisconnected
• Codes HTTP :
  • 408 Request Timeout
  • 429 Too Many Requests
  • 5xx Server Error

Tous les paramètres de la bibliothèque cliente Ruby concernant l'intervalle exponentiel entre les tentatives sont configurables. Par défaut, les opérations via la bibliothèque cliente Ruby utilisent les paramètres suivants pour un intervalle exponentiel entre les tentatives :

Il existe un sous-ensemble d'opérations Ruby idempotentes sous conditions (sous conditions, elles peuvent être relancées en toute sécurité).

• if_generation_match ou generation

  • Vous pouvez effectuer de nouvelles tentatives si le paramètre generation ou if_generation_match est transmis en tant qu'argument à la méthode. Les méthodes n'acceptent souvent que l'un de ces deux paramètres.

• if_metageneration_match

  • Vous pouvez effectuer de nouvelles tentatives si le paramètre if_metageneration_match est transmis en tant qu'option.

Par défaut, toutes les opérations idempotentes font l'objet d'une nouvelle tentative et les opérations idempotentes conditionnelles ne sont relancées que si la condition est remplie. Les opérations non idempotentes ne font pas l'objet de nouvelles tentatives. Consultez la section Personnaliser les nouvelles tentatives pour obtenir des exemples montrant comment modifier le comportement des nouvelles tentatives par défaut.

C++

Pour personnaliser le comportement des nouvelles tentatives, fournissez des valeurs pour les options suivantes lorsque vous initialisez l'objet google::cloud::storage::Client :

• google::cloud::storage::RetryPolicyOption : la bibliothèque fournit les classes google::cloud::storage::LimitedErrorCountRetryPolicy et google::cloud::storage::LimitedTimeRetryPolicy. Vous pouvez fournir votre propre classe, qui doit mettre en œuvre l'interface google::cloud::RetryPolicy.

• google::cloud::storage::BackoffPolicyOption : la bibliothèque fournit la classe google::cloud::storage::ExponentialBackoffPolicy. Vous pouvez fournir votre propre classe, qui doit mettre en œuvre l'interface google::cloud::storage::BackoffPolicy.

• google::cloud::storage::IdempotencyPolicyOption : la bibliothèque fournit les classes google::cloud::storage::StrictIdempotencyPolicy et google::cloud::storage::AlwaysRetryIdempotencyPolicy. Vous pouvez fournir votre propre classe, qui doit mettre en œuvre l'interface google::cloud::storage::IdempotencyPolicy.

Pour en savoir plus, consultez la documentation de référence sur la bibliothèque cliente C++.

namespace gcs = ::google::cloud::storage;
// Create the client configuration:
auto options = google::cloud::Options{};
// Retries only idempotent operations.
options.set<gcs::IdempotencyPolicyOption>(
    gcs::StrictIdempotencyPolicy().clone());
// On error, it backs off for a random delay between [1, 3] seconds, then [3,
// 9] seconds, then [9, 27] seconds, etc. The backoff time never grows larger
// than 1 minute.
options.set<gcs::BackoffPolicyOption>(
    gcs::ExponentialBackoffPolicy(
        /*initial_delay=*/std::chrono::seconds(1),
        /*maximum_delay=*/std::chrono::minutes(1),
        /*scaling=*/3.0)
        .clone());
// Retries all operations for up to 5 minutes, including any backoff time.
options.set<gcs::RetryPolicyOption>(
    gcs::LimitedTimeRetryPolicy(std::chrono::minutes(5)).clone());
return gcs::Client(std::move(options));

C#

Vous ne pouvez pas personnaliser la stratégie de nouvelle tentative par défaut utilisée par la bibliothèque cliente C#.

Go

Lorsque vous initialisez un client de stockage, une configuration par défaut des nouvelles tentatives est définie. Les options de la configuration sont définies sur les valeurs par défaut, sauf si elles sont remplacées. Les utilisateurs peuvent configurer un comportement des nouvelles tentatives autre que celui par défaut, soit pour un seul appel de bibliothèque (à l'aide de BucketHandle.Retryer et ObjectHandle.Retryer), soit pour l'ensemble des appels effectués par un client (à l'aide de Client.SetRetry). Pour modifier le comportement des nouvelles tentatives, transmettez l'option RetryOptions souhaitée à l'une de ces méthodes.

Consultez l'exemple de code suivant pour découvrir comment personnaliser le comportement des nouvelles tentatives.

import (
	"context"
	"fmt"
	"io"
	"time"

	"cloud.google.com/go/storage"
	"github.com/googleapis/gax-go/v2"
)

// configureRetries configures a custom retry strategy for a single API call.
func configureRetries(w io.Writer, bucket, object string) error {
	// bucket := "bucket-name"
	// object := "object-name"
	ctx := context.Background()
	client, err := storage.NewClient(ctx)
	if err != nil {
		return fmt.Errorf("storage.NewClient: %w", err)
	}
	defer client.Close()

	// Configure retries for all operations using this ObjectHandle. Retries may
	// also be configured on the BucketHandle or Client types.
	o := client.Bucket(bucket).Object(object).Retryer(
		// Use WithBackoff to control the timing of the exponential backoff.
		storage.WithBackoff(gax.Backoff{
			// Set the initial retry delay to a maximum of 2 seconds. The length of
			// pauses between retries is subject to random jitter.
			Initial: 2 * time.Second,
			// Set the maximum retry delay to 60 seconds.
			Max: 60 * time.Second,
			// Set the backoff multiplier to 3.0.
			Multiplier: 3,
		}),
		// Use WithPolicy to customize retry so that all requests are retried even
		// if they are non-idempotent.
		storage.WithPolicy(storage.RetryAlways),
	)

	// Use context timeouts to set an overall deadline on the call, including all
	// potential retries.
	ctx, cancel := context.WithTimeout(ctx, 500*time.Second)
	defer cancel()

	// Delete an object using the specified retry policy.
	if err := o.Delete(ctx); err != nil {
		return fmt.Errorf("Object(%q).Delete: %w", object, err)
	}
	fmt.Fprintf(w, "Blob %v deleted with a customized retry strategy.\n", object)
	return nil
}

Java

Lorsque vous initialisez Storage, une instance de RetrySettings est également initialisée. Sauf si elles sont remplacées, les options de RetrySettings sont définies sur les valeurs par défaut. Pour modifier le comportement par défaut des nouvelles tentatives automatiques, transmettez l'option personnalisée StorageRetryStrategy à l'option StorageOptions utilisée pour créer l'instance Storage. Pour modifier l'un des autres paramètres scalaires, transmettez une option personnalisée RetrySettings personnaliséà l'option StorageOptions utilisée pour créer l'instance Storage.

Consultez l'exemple suivant pour découvrir comment personnaliser le comportement des nouvelles tentatives :

import com.google.api.gax.retrying.RetrySettings;
import com.google.cloud.storage.BlobId;
import com.google.cloud.storage.Storage;
import com.google.cloud.storage.StorageOptions;
import com.google.cloud.storage.StorageRetryStrategy;
import org.threeten.bp.Duration;

public final class ConfigureRetries {
  public static void main(String[] args) {
    String bucketName = "my-bucket";
    String blobName = "blob/to/delete";
    deleteBlob(bucketName, blobName);
  }

  static void deleteBlob(String bucketName, String blobName) {
    // Customize retry behavior
    RetrySettings retrySettings =
        StorageOptions.getDefaultRetrySettings()
            .toBuilder()
            // Set the max number of attempts to 10 (initial attempt plus 9 retries)
            .setMaxAttempts(10)
            // Set the backoff multiplier to 3.0
            .setRetryDelayMultiplier(3.0)
            // Set the max duration of all attempts to 5 minutes
            .setTotalTimeout(Duration.ofMinutes(5))
            .build();

    StorageOptions alwaysRetryStorageOptions =
        StorageOptions.newBuilder()
            // Customize retry so all requests are retried even if they are non-idempotent.
            .setStorageRetryStrategy(StorageRetryStrategy.getUniformStorageRetryStrategy())
            // provide the previously configured retrySettings
            .setRetrySettings(retrySettings)
            .build();

    // Instantiate a client
    Storage storage = alwaysRetryStorageOptions.getService();

    // Delete the blob
    BlobId blobId = BlobId.of(bucketName, blobName);
    boolean success = storage.delete(blobId);

    System.out.printf(
        "Deletion of Blob %s completed %s.%n", blobId, success ? "successfully" : "unsuccessfully");
  }
}

Node.js

Lorsque vous initialisez Cloud Storage, un fichier de configuration retryOptions est également initialisé. Les options de la configuration sont définies sur les valeurs par défaut, sauf si elles sont remplacées. Pour modifier le comportement par défaut des nouvelles tentatives, transmettez la configuration de nouvelle tentative personnalisée retryOptions au constructeur de stockage lors de l'initialisation. La bibliothèque cliente Node.js peut utiliser automatiquement des stratégies d'intervalle exponentiel entre les tentatives pour relancer des requêtes avec le paramètre autoRetry.

Consultez l'exemple de code suivant pour découvrir comment personnaliser le comportement des nouvelles tentatives.

/**
 * TODO(developer): Uncomment the following lines before running the sample.
 */
// The ID of your GCS bucket
// const bucketName = 'your-unique-bucket-name';

// The ID of your GCS file
// const fileName = 'your-file-name';

// Imports the Google Cloud client library
const {Storage} = require('@google-cloud/storage');

// Creates a client
const storage = new Storage({
  retryOptions: {
    // If this is false, requests will not retry and the parameters
    // below will not affect retry behavior.
    autoRetry: true,
    // The multiplier by which to increase the delay time between the
    // completion of failed requests, and the initiation of the subsequent
    // retrying request.
    retryDelayMultiplier: 3,
    // The total time between an initial request getting sent and its timeout.
    // After timeout, an error will be returned regardless of any retry attempts
    // made during this time period.
    totalTimeout: 500,
    // The maximum delay time between requests. When this value is reached,
    // retryDelayMultiplier will no longer be used to increase delay time.
    maxRetryDelay: 60,
    // The maximum number of automatic retries attempted before returning
    // the error.
    maxRetries: 5,
    // Will respect other retry settings and attempt to always retry
    // conditionally idempotent operations, regardless of precondition
    idempotencyStrategy: IdempotencyStrategy.RetryAlways,
  },
});
console.log(
  'Functions are customized to be retried according to the following parameters:'
);
console.log(`Auto Retry: ${storage.retryOptions.autoRetry}`);
console.log(
  `Retry delay multiplier: ${storage.retryOptions.retryDelayMultiplier}`
);
console.log(`Total timeout: ${storage.retryOptions.totalTimeout}`);
console.log(`Maximum retry delay: ${storage.retryOptions.maxRetryDelay}`);
console.log(`Maximum retries: ${storage.retryOptions.maxRetries}`);
console.log(
  `Idempotency strategy: ${storage.retryOptions.idempotencyStrategy}`
);

async function deleteFileWithCustomizedRetrySetting() {
  await storage.bucket(bucketName).file(fileName).delete();
  console.log(`File ${fileName} deleted with a customized retry strategy.`);
}

deleteFileWithCustomizedRetrySetting();

PHP

Vous ne pouvez pas personnaliser la stratégie de nouvelle tentative par défaut utilisée par la bibliothèque cliente PHP.

Python

Pour modifier le comportement de nouvelle tentative par défaut, créez une copie de l'objet google.cloud.storage.retry.DEFAULT_RETRY en l'appelant avec une méthode with_XXX. La bibliothèque cliente Python utilise automatiquement des stratégies d'intervalle exponentiel entre les tentatives pour relancer des requêtes si vous incluez le paramètre DEFAULT_RETRY.

Notez que with_predicate n'est pas compatible avec les opérations de récupération ou d'envoi de données de charge utile à des objets, telles que les importations et les téléchargements. Nous vous recommandons de modifier les attributs un par un. Pour en savoir plus, consultez la documentation de référence sur google-api-core Retry.

Pour configurer votre propre nouvelle tentative conditionnelle, créez un objet ConditionalRetryPolicy et encapsulez votre objet Retry personnalisé avec DEFAULT_RETRY_IF_GENERATION_SPECIFIED, DEFAULT_RETRY_IF_METAGENERATION_SPECIFIED, ou DEFAULT_RETRY_IF_ETAG_IN_JSON.

Consultez l'exemple de code suivant pour découvrir comment personnaliser le comportement des nouvelles tentatives.

from google.cloud import storage
from google.cloud.storage.retry import DEFAULT_RETRY


def configure_retries(bucket_name, blob_name):
    """Configures retries with customizations."""
    # The ID of your GCS bucket
    # bucket_name = "your-bucket-name"
    # The ID of your GCS object
    # blob_name = "your-object-name"

    storage_client = storage.Client()
    bucket = storage_client.bucket(bucket_name)
    blob = bucket.blob(blob_name)

    # Customize retry with a deadline of 500 seconds (default=120 seconds).
    modified_retry = DEFAULT_RETRY.with_deadline(500.0)
    # Customize retry with an initial wait time of 1.5 (default=1.0).
    # Customize retry with a wait time multiplier per iteration of 1.2 (default=2.0).
    # Customize retry with a maximum wait time of 45.0 (default=60.0).
    modified_retry = modified_retry.with_delay(initial=1.5, multiplier=1.2, maximum=45.0)

    # blob.delete() uses DEFAULT_RETRY_IF_GENERATION_SPECIFIED by default.
    # Override with modified_retry so the function retries even if the generation
    # number is not specified.
    print(
        f"The following library method is customized to be retried according to the following configurations: {modified_retry}"
    )

    blob.delete(retry=modified_retry)
    print(f"Blob {blob_name} deleted with a customized retry strategy.")

Ruby

Lorsque vous initialisez le client de stockage, toutes les configurations de nouvelles tentatives sont définies selon les valeurs indiquées dans le tableau ci-dessus. Pour modifier le comportement des nouvelles tentatives par défaut, transmettez les configurations de nouvelles tentatives lors de l'initialisation du client de stockage.

Pour forcer le nombre de tentatives pour une opération particulière, transmettez retries dans le paramètre options de l'opération.

def configure_retries bucket_name: nil, file_name: nil
  # The ID of your GCS bucket
  # bucket_name = "your-unique-bucket-name"

  # The ID of your GCS object
  # file_name = "your-file-name"

  require "google/cloud/storage"

  # Creates a client
  storage = Google::Cloud::Storage.new(

    # The maximum number of automatic retries attempted before returning
    # the error.
    #
    # Customize retry configuration with the maximum retry attempt of 5.
    retries: 5,

    # The total time in seconds that requests are allowed to keep being retried.
    # After max_elapsed_time, an error will be returned regardless of any
    # retry attempts made during this time period.
    #
    # Customize retry configuration with maximum elapsed time of 500 seconds.
    max_elapsed_time: 500,

    # The initial interval between the completion of failed requests, and the
    # initiation of the subsequent retrying request.
    #
    # Customize retry configuration with an initial interval of 1.5 seconds.
    base_interval: 1.5,

    # The maximum interval between requests. When this value is reached,
    # multiplier will no longer be used to increase the interval.
    #
    # Customize retry configuration with maximum interval of 45.0 seconds.
    max_interval: 45,

    # The multiplier by which to increase the interval between the completion
    # of failed requests, and the initiation of the subsequent retrying request.
    #
    # Customize retry configuration with an interval multiplier per iteration of 1.2.
    multiplier: 1.2
  )

  # Uses the retry configuration set during the client initialization above with 5 retries
  file = storage.service.get_file bucket_name, file_name

  # Maximum retry attempt can be overridden for each operation using options parameter.
  storage.service.delete_file bucket_name, file_name, options: { retries: 4 }
  puts "File #{file.name} deleted with a customized retry strategy."
end