Why Isn’t My AggregateException Caught in Try-Catch When Using Parallel.ForAsync with Polly on VPN Disconnect?

Based on the behavior you’re describing and the exception’s call stack, it appears that the exception isn’t thrown from within your async lambda (and thus not caught by your inner try‑catch) but later on a thread‑pool or timer thread that isn’t covered by your try‑catch scope.

Below are a few points to consider:

1. Unhandled exceptions in background work:
   The call stack shows the exception emanates from internal timer callbacks and cancellation token callbacks (inside MySql.Data), which means it’s occurring on a thread separate from your awaited task. When an exception is thrown on a thread‐pool thread that isn’t awaited or wrapped in a try‑catch (or is thrown after your async lambda has already completed), it won’t be caught by your inner try‑catch block.

2. AggregateException from task APIs:
   Some Task‑based methods (such as Task.WaitAll, Task.WhenAll, or even Parallel.ForAsync) can wrap exceptions in an AggregateException if more than one task faults. When you await Parallel.ForAsync, if one or more tasks fault, that exception is rethrown to the caller (often as an AggregateException or its inner exception). To catch it, you need to wrap the await call in a try‑catch. For example:

   CSHARPCopied
   try
   {
       await Parallel.ForAsync(0, totalBatchesCount, parallelOptions, async (i, cancellationToken) =>
       {
           await retryPolicy.ExecuteAsync(async () =>
           {
               try
               {
                   var batch = await _userRepository.GetBatchAsync(startId, endId);
                   // Process batch...
               }
               catch (Exception ex)
               {
                   throw new Exception($"Batch failed for startId: {startId} and endId {endId}", ex);
               }
           });
       });
   }
   catch (AggregateException ex)
   {
       // Handle aggregated exceptions if necessary.
       _logger.LogError(ex, "One or more errors occurred during processing.");
   }
   catch (Exception ex)
   {
       // Handle any other exceptions.
       _logger.LogError(ex, "An error occurred during parallel processing.");
   }

3. VPN disconnect causing an unusual timing scenario:
   Since you’re testing with a VPN disconnection, the underlying networking (or MySql client) code might be using timers to abort the operation. In that case, the exception is thrown from a callback that isn’t directly part of your async control flow. Once that exception escapes into the thread‑pool and isn’t observed by your awaited task (or is re‑thrown later), it won’t be caught in the inner try‑catch.

4. Polly retry policy scope:
   The Polly retry policy is handling exceptions thrown within the delegate passed to ExecuteAsync. However, if the exception occurs outside that delegate (for example, in a timer callback on the MySql client), Polly won’t have a chance to capture it.

Recommendations to help mitigate or diagnose the issue:

• Make sure you wrap the entire Parallel.ForAsync call in a try‑catch (as shown above) so that any exceptions that are eventually re‑thrown are caught in a centralized place.
• If the exception is being thrown by the MySql client’s internal timer (possibly due to the VPN disconnect), consider subscribing to the TaskScheduler.UnobservedTaskException event or using a global exception handler so you can log the exception details.
• Check whether the MySql client supports cancellation or timeout configuration that might allow more graceful handling in scenarios like network disconnections.

In summary, the exception isn’t caught in your try‑catch because it is thrown outside the execution context of your lambda (via a timer callback) and is aggregated by the task infrastructure outside the scope of your inner try‑catch. Catching it properly requires surrounding your awaited Parallel.ForAsync call with try‑catch and/or handling unobserved task exceptions at the application level.