Fatal Exception: android.database.sqlite.SQLiteConstraintException FOREIGN KEY constraint failed (code 787) [114705286]

Fixed

Bug

Status Update

No update yet.

Description

[Deleted User]

created issue #1

Sep 10, 2018 07:08PM

Component used:WorkManager
Version used:1.0.0-alpha08
Devices reproduced on:Xiaomi, Motorola, Samsung, Oppo, etc
Android versions reproduced on:6,7,8,9

We are facing this crash with 2 stack traces :

android.database.sqlite.SQLiteConnection.nativeExecuteForLastInsertedRowId (SQLiteConnection.java)
android.database.sqlite.SQLiteConnection.executeForLastInsertedRowId (SQLiteConnection.java:812)
android.database.sqlite.SQLiteSession.executeForLastInsertedRowId (SQLiteSession.java:788)
android.database.sqlite.SQLiteStatement.executeInsert (SQLiteStatement.java:86)
android.arch.persistence.db.framework.FrameworkSQLiteStatement.executeInsert (SourceFile:50)
android.arch.persistence.room.EntityInsertionAdapter.bind (SourceFile:64)
androidx.work.impl.model.SystemIdInfoDao_Impl.insertSystemIdInfo (SourceFile:52)
androidx.work.impl.background.systemjob.SystemJobScheduler.schedule (SourceFile:92)
androidx.work.impl.Schedulers.schedule (SourceFile:99)
androidx.work.impl.utils.EnqueueRunnable.scheduleWorkInBackground (SourceFile:114)
androidx.work.impl.utils.EnqueueRunnable.run (SourceFile:86)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1113)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:588)
java.lang.Thread.run (Thread.java:818)

android.database.sqlite.SQLiteConnection.nativeExecuteForLastInsertedRowId (SQLiteConnection.java)
android.database.sqlite.SQLiteConnection.executeForLastInsertedRowId (SQLiteConnection.java:812)
android.database.sqlite.SQLiteSession.executeForLastInsertedRowId (SQLiteSession.java:788)
android.database.sqlite.SQLiteStatement.executeInsert (SQLiteStatement.java:86)
android.arch.persistence.db.framework.FrameworkSQLiteStatement.executeInsert (SourceFile:50)
android.arch.persistence.room.EntityInsertionAdapter.bind (SourceFile:64)
androidx.work.impl.model.SystemIdInfoDao_Impl.insertSystemIdInfo (SourceFile:52)
androidx.work.impl.background.systemjob.SystemJobScheduler.schedule (SourceFile:92)
androidx.work.impl.Schedulers.schedule (SourceFile:99)
androidx.work.impl.WorkManagerImpl.rescheduleEligibleWork (SourceFile:555)
androidx.work.impl.utils.ForceStopRunnable.run (SourceFile:74)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1113)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:588)
java.lang.Thread.run (Thread.java:818)

Here is the fabrics link for this crash:

http://crashes.to/s/50397ac3f50

Comments

su...@google.com <su...@google.com> #2Sep 17, 2018 06:17PM

We introduced a regression in beta02. Can you try using beta01 instead ?

[Deleted User] <[Deleted User]> #3Sep 17, 2018 06:30PM

Also, beta03 is coming with a fix very soon.

ap...@google.com <ap...@google.com> #4Sep 17, 2018 09:29PM

Thank you for your prompt response. I've checked the functioning of OneTimeWorkRequest in beta01 and it works as expected. Looking forward to beta03 for the fix.

su...@google.com <su...@google.com> #5Sep 17, 2018 09:29PM

beta03 is out.

ap...@google.com <ap...@google.com> #6Sep 18, 2018 09:28PM

In beta03, the bug seems fixed when JobScheduler backend is used.
But the bug seems to remain when AlarmManager backend is used.

The following step-by-step fails for me on emulator "Nexus 7 (2012) API 22", but passes on emulator "Pixel 2 XL API 27".

STEP BY STEP:
1. Create a "Hello world" Android app using Android Studio wizard and add implementation("android.arch.work:work-runtime:1.0.0-beta03") to dependencies
2. Add the following to MainActivity.onCreate():

final String name = Long.toString(System.currentTimeMillis()); // To ensure fresh name each run
final OneTimeWorkRequest workRequest = new OneTimeWorkRequest.Builder(LogPrinter.class)
.setBackoffCriteria(BackoffPolicy.LINEAR, WorkRequest.MIN_BACKOFF_MILLIS, TimeUnit.MILLISECONDS)
.addTag(name)
.build();
Log.e("Repro", "Calling enqueueUniqueWork(" + name + ", ...)");
WorkManager.getInstance().enqueueUniqueWork(name, ExistingWorkPolicy.REPLACE, workRequest);

where LogPrinter.class doWork() is:

@NonNull
@Override
public Result doWork() {
Log.e("Repro", "doWork() called. Now swipe away app in App Switcher. Tags: " + getTags());
SystemClock.sleep(10000);
Log.e("Repro", "Too late, try again. Tags: " + getTags());
return Result.success();
}

3. Run the app and check adb logcat -s Repro
4. When you see "Now swipe away app in App Switcher", do that.

EXPECTED:
You should see "doWork() called ..." again after max 10 seconds (due to specified backoff time), since the WorkManager framework should ensure that the Worker that never was finished gets a chance to run again.

ACTUAL:
On API 22, you never see "doWork() called ..." again (Test fails).
On API 27, you do see "doWork() called ..." again (Test pass).

Let me know if you need more input.

Best regards,
Martin Nordholts

su...@google.com <su...@google.com> #7Sep 25, 2018 08:02PM

Marked as fixed, reassigned to su...@google.com.

When a swipe to dismiss happens you should see a message in logcat which looks like:

W/ActivityManager( 1532): Scheduling restart of crashed service androidx.work.integration.testapp/androidx.work.impl.background.systemalarm.SystemAlarmService in 47470ms

Service crashes are different from Worker retries or backoffs. So you won't see it in 10 seconds. It might take longer. Look at the logs for more info.

ak...@gmail.com <ak...@gmail.com> #8Dec 1, 2022 06:41PM

Thanks for the tip, this helped me debug this further.

Turns out that if you see "Scheduling restart of crashed service", then yes, doWork() will be called after the specified time.
But the problem is that SystemAlarmService is not always scheduled to restart, because SystemAlarmService is not always running when the app is closed.
In fact, it seems to be quite rare for SystemAlarmService to run.

If you increase the sleep from 10000 to 20000 in my step-by-step instructions, and let 10 seconds pass between ""doWork() called .., " being logged and you closing the app, I think you'll be able to reproduce the problem, namely that doWork() never becomes called again (since SystemAlarmService is not scheduled for a restart, since it wasn't running when the app was closed).

Are you able to reproduce the problem with these extra instructions?

mw...@gmail.com <mw...@gmail.com> #9Apr 21, 2023 09:31AM

Can you please turn on verbose logging and send us all the logs ? I am going to try and reproduce this on my end.

You will need to initialize WorkManager with a custom configuration for that.

* Remove the default WorkManager initializer using:

<provider
android:name="androidx.work.impl.WorkManagerInitializer"
android:authorities="${applicationId}.workmanager-init"
tools:node="remove"/>

* Initialize WorkManager in your own content provider or Application#onCreate() with a custom configuration

WorkManager.initialize(
applicationContext,
new Configuration.Builder().setMinimumLoggingLevel(Log.VERBOSE).build());

You will see a lot more WorkManager logs now.

Fri Apr 21 2023 14:59:31 GMT+0530 (India Standard Time).png

198 KB

View

Download

xu...@gmail.com <xu...@gmail.com> #10Jul 10, 2023 03:23AM

I think I know what is going on. There are 2 competing schedulers that can pick up work. When the in-process scheduler picks up work and the process gets killed there is nothing else that can wake up to reschedule that Worker until the application is launched again.