Tengo un método genérico para ejecutar tareas asíncronas en un contexto síncrono con reintentos.
public static T RunWithRetries<T>(Task<T> task) { while(...) // 3 attempts { try { task.GetAwaiter().GetResult(); } catch { // sleep & retry later in case of some exceptions, for example 429 } } }Luego paso cualquier método de la API asíncrona para ejecutarlo de esta manera.
SyncHelper.RunWithRetries(externalAPI.UploadAsync(fileRequest, fileStream));El problema es que funciona a menos que ocurra una excepción durante la solicitud y necesitemos volver a intentarlo. Si ocurre un error, todos los reintentos subsiguientes también generarán la misma excepción. entonces mis preguntas son
¿Está sucediendo esto debido al objeto
fileStream? Está en la declaración de uso, por lo que no se eliminará con seguridad. ¿La posición de transmisión después del primer intento de carga puede ser un problema?
Sí, este es uno de tus problemas. Cada vez que se lee un flujo, su Position no se restablece a 0 automáticamente. Si intenta volver a leerlo, no leerá nada, ya que la posición se encuentra al final de la transmisión.
Por lo tanto, debe crear una nueva secuencia cada vez o rebobinar la secuencia hasta el principio .
¿Es normal que se vuelva a intentar el mismo objeto Tarea? ¿Debería cambiar la forma en que lo hago por algo mejor?
Siempre que una tarea haya finalizado (ya sea con un resultado particular o con una excepción), volver a await o recuperar su Result no desencadenará una nueva ejecución. Simplemente devolverá el valor o la excepción.
Por lo tanto, debe crear una nueva tarea para cada reintento. Para hacerlo, podría anticipar una Func<Task<T>> en su RunWithRetries
public static T RunWithRetries<T>(Func<Task<T>> issueRequest) { ... issueRequest().GetAwaiter().GetResult(); }Desde el lado de la persona que llama se vería así:
RunWithRetries(() => externalAPI.UploadAsync(fileRequest, new FileStream(...))); //or RunWithRetries(() => { fileStream.Position = 0; externalAPI.UploadAsync(fileRequest, fileStream); });