IssueTracker

That is not what is happening here.

ConstraintTrackingWorker uses another ListenableWorker as its delegate. Essentially tracking constraints for the other delegated ListenableWorker instance. So mDelegate is a completely different ListenableWorker istance.

So this is the sequence of events as I see it:

ConstraintTrackingWorker.onStopped() -> ListenableWorker.onStopped() [No-op]
    |
    |-> `mDelegate.stop()` -> -> ListenableWorker.onStopped() [No-op] -> `mDelegate.onStopped()`. 

There is a minor optimization that we could make here, i.e. call stop() only if the delegate was not previously stopped. But I still don't see how this can cause a StackOverFlow.

--

I also tried to reproduce the bug to make sure this is what happens. And these are the sequence of events that I am seeing. I can still make the optimization I was referring to, but I don't really know what is causing the StackOverflowException here. What does your ListenableWorker look like ?

I still haven't been able to repro this locally, but did find that we were creating a single work request instance and enqueueing it multiple times. Perhaps that could cause this issue?

I have a theory on how you could end up in this situation.

If you are using a custom WorkerFactory you need to make sure that you do not return a ListenableWorker instance when the fully qualified class name of the Worker points to ConstraintTrackingWorker.

I still haven't been able to repro this locally, but did find that we were creating a single work request instance and enqueueing it multiple times. Perhaps that could cause this issue?

That should not result in this happening. Unless you are creating new WorkRequest ids which all get treated as new work requests.

Unfortunately, we're not using WorkerFactory at all. Here's what our current code looks like:

private const val UNIQUE_WORK_NAME = "some_string"

internal class SomeClass(private val application: Application) {
    private val constraints = Constraints.Builder()
        .setRequiresBatteryNotLow(true)
        .setRequiredNetworkType(NetworkType.CONNECTED)
    .build()

    private val workRequest = OneTimeWorkRequestBuilder<SomeWorker>()
        .addTag(UNIQUE_WORK_NAME)
        .setConstraints(constraints)
    .build()

    override suspend fun submitUploadRequest(force: Boolean) {
        WorkManager.getInstance(application).enqueueUniqueWork(
            UNIQUE_WORK_NAME,
            if (force) ExistingWorkPolicy.REPLACE else ExistingWorkPolicy.KEEP,
            workRequest
        )
    }
}

internal class SomeWorker(
    appContext: Context,
    params: WorkerParameters
) : CoroutineWorker(appContext, params) {
    override suspend fun doWork(): Result = TODO("Omitted")
}

Two more data points based on reports:

1. We're only seeing this crash on Android 7.x
2. Most common devices: Huawei Mate 10 lite, Huawei P9 lite, Samsung Galaxy S6

Still trying to repro - no luck so far with API 24 emulator.

We're only seeing this crash on Android 7.x

This makes sense. Because ConstraintTrackingWorker is only used in API 23-25.

I am also seeing something similar reported for a Huawei P8 Lite on Android 7.0

Fatal Exception: java.lang.StackOverflowError: stack size 1037KB
       at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
       at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
       at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
       at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
       at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
       at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
       at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
       at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
       at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
       at androidx.work.impl.workers.ConstraintTrackingWorker.isRunInForeground(ConstraintTrackingWorker.java:187)
       at androidx.work.impl.WorkerWrapper.resolve(WorkerWrapper.java:447)
       at androidx.work.impl.WorkerWrapper.tryCheckForInterruptionAndResolve(WorkerWrapper.java:419)
       at androidx.work.impl.WorkerWrapper.interrupt(WorkerWrapper.java:375)
       at androidx.work.impl.Processor.interrupt(Processor.java:331)
       at androidx.work.impl.Processor.stopWork(Processor.java:188)
       at androidx.work.impl.utils.StopWorkRunnable.run(StopWorkRunnable.java:73)
       at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
       at java.lang.Thread.run(Thread.java:776)

Is this related at all? Or is it a separate issue?