Raster mode tile cancellation

[stefcon]

Whenever I do fast zoom in/out, I'm getting following error:

══╡ EXCEPTION CAUGHT BY IMAGE RESOURCE SERVICE ╞════════════════════════════════════════════════════
The following CancellationException was thrown:
Cancelled

When the exception was thrown, this was the stack:
#0      TileLoader._renderTile (package:vector_map_tiles/src/raster/tile_loader.dart:72:7)
#1      TileLoader._renderJob (package:vector_map_tiles/src/raster/tile_loader.dart:66:40)
#2      ImmediateExecutor.submit (package:executor_lib/src/immdediate_executor.dart:17:44)
#3      ConcurrencyExecutor._startJob (package:executor_lib/src/concurrency_executor.dart:71:10)
#4      ConcurrencyExecutor._startJobs (package:executor_lib/src/concurrency_executor.dart:57:7)
#5      ConcurrencyExecutor.submit (package:executor_lib/src/concurrency_executor.dart:39:5)
#6      TileLoader.loadTile (package:vector_map_tiles/src/raster/tile_loader.dart:61:22)
<asynchronous suspension>
#7      _FutureImageProvider._load.<anonymous closure> (package:vector_map_tiles/src/raster/future_tile_provider.dart:64:47)
<asynchronous suspension>
════════════════════════════════════════════════════════════════════════════════════════════════════

I saw that in latest release note for 7.3.1 it is noted that it has something to do with that:

• support cancellation in raster tile provider

The problem is that visibly slows down the map when it happens, and in addition it also overflows my crashlytics service. Is there some way that this is supposed to be handled outside the library and is it something that is being worked on currently? Also, If someone would like to explain why this feature is now being handled this way and what it enables generally would be great.

[PatrickWulfe]

I'm also having issues with the package overflowing my crashlytics service.

[greensopinion]

Likely there's somewhere in the code that we're not handling exceptions across an async boundary, causing exceptions to go to the default exception handler. https://dart.dev/libraries/async/futures-error-handling#potential-problem-failing-to-register-error-handlers-early

A couple of options come to mind:

• find and fix the defect in this library
• handle exceptions with PlatformDispatcher.instance.onError = ...yourhandler https://docs.flutter.dev/testing/errors#handling-all-types-of-errors

[mart-fractic]

Thank you very much for the response. The following works for me to suppress the errors (and in my case, let integration tests now pass with a zero exit code).

// flutter pub add executor_lib
import "package:executor_lib/executor_lib.dart";

void main() async {
  final originalHandler = FlutterError.onError;
  FlutterError.onError = (details) {
    // Flutter map currently has a bug with async vector tile loading. On
    // cancellation (i.e. when a request for a tile has been sent but its result
    // is no longer necessary), a CancellationException is throw and not
    // properly handled. Silently ignore this exception type.
    if (details.exception is CancellationException) {
      return;
    }
    FlutterError.presentError(details);
    // Integration tests rely on overriding FlutterError.onError, so if we are
    // in integration tests mode we must take care to also call the original
    // handler.
    if (kIntegrationTest) originalHandler?.call(details);
  };
  return runApp(...);
}

[markvideon]

Hi there,

Managed to trace various cancellation exceptions in my application that were being handled by the PlatformDispatcher callback to the following places:

• Inside createTiles where testCancelled is being invoked
• Inside FutureTileProvider's _load method. The ImageStreamCompleter doesn't have any listeners on it - the default behaviour when this is the case is to bubble the error up to the top-level error handler. I was able to suppress the errors by adding a listener (see: ImageStreamListener) and specifying an onError callback. Perhaps a custom onError callback is something that the package could allow applications to specify on this completer and any others where appropriate

[greensopinion]

Thanks for looking into it Mark. In most (all?) cases CancellationException is not useful for this library. For example, when we receive a CancellationException do we dispose of any resources?

I wonder if it would make sense to wrap Executor (from executor_lib) in an executor that simply swallows all CancellationException on futures? If we did that, we could have a solution that fits all cases without having to chase them all down.

Alternatively we could address the specific cases that you discovered. Unless it's needed, I recommend against configurability since it would add unnecessary complexity.