IssueTracker

In our case, we have b2b app running on dedicated devices.

After 1.1.0 DataStore update we had 6 terminals reported 30k androidx.datastore.core.CorruptionException fatal crashes on app start.

We use DataStore in WorkManager jobs and on regular Activity starts. Seems that after the application gets this state it will never will succeed to start successfully again. I am afraid that data is being corrupted.

Can't reproduce. But same as OP, we have very vanilla usage of DataStore Preferences. No multiple processes, just simple read/write key-values in a single process single Activity.

Hi, thanks for the feedback, noticed the number of +1s, I'll prioritize an investigation.

To facilitate the process, could you please share how you create the DataStore instance?

Here is how we are creating our DataStore<Preferences> instances:

PreferenceDataStoreFactory.create(
    produceFile = { context.preferencesDataStoreFile(filename) }, // filename is [a-zA-Z]
    scope = scope, // CoroutineScope(Dispatchers.IO + SupervisorJob())
    migrations = listOf(
        SharedPreferencesMigration(
            context = context,
            sharedPreferencesName = sharedPrefFile, // we are using our package name here
            keysToMigrate = keysToMigrate, // a Set<String>, sometimes empty if nothing to be migrated
        ),
    ),
    corruptionHandler = ReplaceFileCorruptionHandler {
        // logging step omitted
        emptyPreferences()
    },
)

And these methods are called in Hilt @Provides methods in a @InstallIn(SingletonComponent::class) @Module for each preferences we use in our app.

@Module
@InstallIn(SingletonComponent::class)
class PreferencesDataStoreModule {

    @Provides
    @Singleton
    fun provideDataStore(@ApplicationContext context: Context): DataStore<Preferences> =
        PreferenceDataStoreFactory.create(
            produceFile = {
                context.preferencesDataStoreFile(PREFERENCES_FILE_NAME)
            },
        )
}

Re #comment8 and #comment10, you'll need to configure a corruptionHandler to handle the corrupted data file, like in #comment7, otherwise the library doesn't proactively fix the data corruption.