IssueTracker

filterSync is eventually called within Flow<PagingData>.map, so I believe it runs in the collector's context, unless .flowOn is called, but I may be incorrect here. I think it would be worthwhile to add a param to allow control over where it gets dispatched (including parallel executor API, since Java users won't normally use Coroutines directly), but maybe *Sync is a bad name if we do that.

It seems like the ideal API would be something like PagingData.map(executor, transform), and we could even deprecate the sync versions with a default arg / overload since their only purpose was to allow java callers to call into the suspending transforms.

Happy to take a PR for this change and to talk it through in more detail if you're interested in taking it on! Maybe we could sketch out what the API should be in a shared doc?

At the very least this bug definitely points to some holes in the sync transform APIs and I'm happy to slot some time for this bug if you were only interested in making small doc changes (totally understandable).

Thanks for the information.

Taking in into account, I think it'd be best to have filter, map, flatMap and their Sync suffixed variants run on Dispatchers.Default by default, since it's very very likely that we get CPU bound operations there, such as searching for filtering, allocating to create instances of other types from the input data…

Regarding the name of the Java API… I agree a little that "*Sync is a bad name", and I think Blocking would be more accurate on the Kotlin side (while keeping the non suffixed @JvmName for Java callers). That is related to the issue where I ask to discourage or prevent use of the API for Java callers in Kotlin code: https://issuetracker.google.com/issues/172851314

Maybe we could sketch out what the API should be in a shared doc?

Yes we can! You can send it here, or we can also chat on ASG or Kotlin Slack if you're there (I'm Louis CAD).

Since it's not what I expected (not run on Dispatchers.Default, I think it's best to talk more about the design before considering a PR.

Thanks - I sent you a message and started a doc, these are definitely some valid concerns!