IssueTracker

Related bug - https://issuetracker.google.com/issues/124511903

Initial loads in LimitOffsetPagingSource run in transaction but subsequent loads do not because of cost of transaction. Loads rely on count query to return correct LoadResult.

If count query is outdated, i.e. large amount of data deleted, LimitOffsetPagingSource can return i.e. empty/wrong data and incorrect itemsBefore/itemsAfter/prevKey/nextKey. This can happen if outdated PagingSource doesn't get invalidated in time.

Project: platform/frameworks/support
Branch: androidx-main

commit 6bd2347ff259c28b34789c8569b7a298d2a8fd8d
Author: Clara Fok <clarafok@google.com>
Date:   Fri Jul 09 12:53:22 2021

    Implement Invalid return type in PagingSource
   
    Added third return type for LoadResult sealed class in PagingSource. It
    was added as a support feature to handle race scenarios between data loads
    and database invalidations, such as if Room's InvalidationTracker does
    not propagate invalidation signal to the PagingSource in time and the
    PagingSource continues querying an updated database. This can result in
    data being loaded onto a stale PageFetcherSnapshot causing duplicated or
    missing data. Related bug regarding race scenario in Room b/191806126.
   
    For example, if data was deleted and items shifted positions,
    positionally-keyed paging sources can end up loading duplicated items.
   
    Paging handles this return type by discarding the loaded data and
    invalidating the paging source. This will trigger a new paging source to
    be generated. This return type is also supported for Paging2 APIs
    leveraging PagingSource such as LivePagedList and RxPagedList.
   
    Aside from handling invalid data due to races, this return type can be
    leveraged in general where the database or network returns potentially
    invalid or stale data that needs to be discarded.
   
    Bug: 192013267
    Test: ./gradlew :paging:paging-common:test
    Relnote: "A third LoadResult return type LoadResult.Invalid is added to
        PagingSource. When a PagingSource.load returns
        LoadResult.Invalid, paging will discard the loaded data and
        invalidate the PagingSource. This return type is designed to
        handle potentially invalid or stale data that can be returned
        from the database or network.
   
        For example, if the underlying database gets written into but
        the PagingSource does not invalidate in time, it may return
        inconsistent results if its implementation depends on the
        immutability of the backing dataset it loads from (e.g., LIMIT
        OFFSET style db implementations). In this scenario, it is
        recommended to check for invalidation after loading and to
        return LoadResult.Invalid, which causes Paging to discard any
        pending or future load requests to this PagingSource and
        invalidate it.
   
        This return type is also supported by Paging2 API that leverages
        LivePagedList or RxPagedList. When using a PagingSource with
        Paging2's PagedList APIs, the PagedList is immediately detached,
        stopping further attempts to load data on this PagedList and
        triggers invalidation on the PagingSource.
   
        LoadResult is a sealed class, which means this is a
        source-incomptabile change such that use cases directly using
        PagingSource.load results will have to handle LoadResult.Invalid
        at compile time. For example, Kotlin users leveraging
        exhaustive-when to check return type will have to add a check
        for Invalid type."
   
    Change-Id: Id6bd3f2544f1ba97a95a0d590353438a95fedf2a

M       paging/common/api/current.txt
M       paging/common/api/public_plus_experimental_current.txt
M       paging/common/api/restricted_current.txt
M       paging/common/src/main/kotlin/androidx/paging/PageFetcherSnapshot.kt
M       paging/common/src/main/kotlin/androidx/paging/PagedList.kt
M       paging/common/src/main/kotlin/androidx/paging/PagingSource.kt
M       paging/common/src/test/kotlin/androidx/paging/PageFetcherSnapshotTest.kt
M       paging/common/src/test/kotlin/androidx/paging/PageFetcherTest.kt
M       paging/common/src/test/kotlin/androidx/paging/PagedListTest.kt
M       paging/common/src/test/kotlin/androidx/paging/PagingDataDifferTest.kt
M       paging/common/src/test/kotlin/androidx/paging/PagingSourceTest.kt
M       paging/integration-tests/testapp/src/main/java/androidx/paging/integration/testapp/v3room/V3RemoteMediator.kt
M       paging/integration-tests/testapp/src/main/java/androidx/paging/integration/testapp/v3room/V3RoomViewModel.kt

https://android-review.googlesource.com/1747297

Project: platform/frameworks/support
Branch: androidx-main

commit 3882ac8364fd905c9935d38c93f84599009226d6
Author: Clara Fok <clarafok@google.com>
Date:   Fri Jul 09 14:17:48 2021

    Implement LoadResult.Invalid to handle race
   
    For non-initial loads in LimitOffsetPagingSource, loads will run Room
    InvalidationTracker's refreshVersionSync to synchronously check if
    tables have been invalidated and notify observers. If invalidated,
    load will return LoadResult.Invalid.
   
    Paging3 will handle Invalid return type by invalidating the paging
    source and closing the page event flow, such that no more loads will be
    attempted on this paging source.
   
    Note that refreshVersionSync is a temporary solution for
    LimitOffsetPagingSource to check table invalidation. Another solution
    that does not require a transaction is in development. Related b/192269858.
   
    Bug: 191806126
    Test: ./gradlew :room:integration-tests:room-testapp-kotlin:cC
    Test: ./gradlew room:room-paging:cC
    Change-Id: I48634ab95949bae608374f5156a4edd0500a74a3

M       room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/PagingSourceTest.kt
M       room/room-paging/build.gradle
M       room/room-paging/src/androidTest/kotlin/androidx/room/paging/LimitOffsetPagingSourceTest.kt
M       room/room-paging/src/main/kotlin/androidx/room/paging/LimitOffsetPagingSource.kt

https://android-review.googlesource.com/1761130

Now that you blocked the existing workaround to use your WorkManager with direct boot, is there a chance that we will get official direct boot support in the near future?

Our app relies heavily on WorkManager to ensure consistent task scheduling, and we were just about to implement direct boot support for our app.

The intentional exception forces us to consider using an alternative task scheduling, only to achieve direct boot support...
But going this way does not seem sensible. WorkManager is the official recommended way to schedule tasks by Google, not supporting direct boot AND taking away the conscious decision to use WorkManger in a device encrypted environment, does not make sense to me.

Expecting the response, any ETA of new WorkManager which supports direct boot aware?

Any updates on Direct Boot mode support for WorkManager? If it is already available please specify the version here.

Is there any progress on this? I have had to rework my code to use JobScheduler directly due to the lack of direct boot support for workmanager, it's a real shame