Status Update
Comments
an...@gmail.com <an...@gmail.com> #2
ra...@google.com <ra...@google.com>
[Deleted User] <[Deleted User]> #3
gh...@google.com <gh...@google.com> #4
an...@gmail.com <an...@gmail.com> #5
tn...@google.com <tn...@google.com> #6
an...@gmail.com <an...@gmail.com> #7
an...@gmail.com <an...@gmail.com> #8
wo...@gmail.com <wo...@gmail.com> #9
The behavior is actually consistent. Once your worker starts running, if we get a call to enqueueUniquePeriodicWork a new work request and with ExistingPeriodicWorkPolicy.REPLACE we will stop existing work.
If your Worker was not running, then there is nothing to cancel. This is just a matter of timing.
wo...@gmail.com <wo...@gmail.com> #10
di...@gmail.com <di...@gmail.com> #11
wo...@gmail.com <wo...@gmail.com> #12
[Deleted User] <[Deleted User]> #13
[Deleted User] <[Deleted User]> #14
So essentially, your worker starts, and mid-way the constraints are unmet. At this point because your Worker may not recover gracefully, we cancel and reschedule work. This happens for all your workers actually (if you turn on verbose logging you can see that).
This too is expected.
an...@gmail.com <an...@gmail.com> #15
[Deleted User] <[Deleted User]> #16
#15: File a separate bug, with sample code or a sample app. The issue is vague enough that there could be something completely different happening.
an...@gmail.com <an...@gmail.com> #17
gh...@google.com <gh...@google.com> #18
java.util.concurrent.CancellationException: Task was cancelled.
at androidx.work.impl.utils.futures.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:1184)
at androidx.work.impl.utils.futures.AbstractFuture.getDoneValue(AbstractFuture.java:514)
at androidx.work.impl.utils.futures.AbstractFuture.get(AbstractFuture.java:475)
at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:245)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)
In our case:
fun scheduleHighlightsSync() {
val request = PeriodicWorkRequest.Builder(SyncHighlightsWorker::class.java, 1, TimeUnit.HOURS)
.setConstraints(Constraints.Builder()
.setRequiredNetworkType(NetworkType.CONNECTED)
.setRequiresBatteryNotLow(true)
.build())
.build()
WorkManager.getInstance().enqueueUniquePeriodicWork(SYNC_HIGHLIGHTS,
ExistingPeriodicWorkPolicy.KEEP, request)
}
according to the logs TimeUnit.HOURS is ignored and we get them several times per second on SDK < 23
an...@gmail.com <an...@gmail.com> #19
01-09 18:36:22.450 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerB: I did some work
01-09 18:36:22.740 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerC: I did some work
01-09 18:36:22.750 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerD: I did some work
01-09 18:36:23.050 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerE: I did some work
01-09 18:36:52.350 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerA: I did some work
01-09 18:36:52.360 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerB: I did some work
01-09 18:36:52.650 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerC: I did some work
01-09 18:36:52.650 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerD: I did some work
01-09 18:36:52.950 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerE: I did some work
01-09 18:37:22.350 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerA: I did some work
01-09 18:37:22.380 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerB: I did some work
01-09 18:37:22.660 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerC: I did some work
01-09 18:37:22.680 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerD: I did some work
01-09 18:37:22.960 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerE: I did some work
01-09 18:38:22.350 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerA: I did some work
01-09 18:38:22.390 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerB: I did some work
01-09 18:38:22.660 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerC: I did some work
01-09 18:38:22.690 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerD: I did some work
01-09 18:38:22.950 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerE: I did some work
Logs when all workers are affected. Even though Result.sucess() was returned, due to this issue, WorkManager keeps retrying them. You can see the exponential backoff starting at 30 sec and going to 1 min, 2 min, 4 min etc
an...@gmail.com <an...@gmail.com> #20
br...@google.com <br...@google.com> #21
gh...@google.com <gh...@google.com> #23
ws...@gmail.com <ws...@gmail.com> #24
gh...@google.com <gh...@google.com> #25
ws...@gmail.com <ws...@gmail.com> #26
gh...@google.com <gh...@google.com> #27
Oh, I misunderstood. So, using lint.do.not.reuse.uast.env
is what causes the new crash? That is unfortunate, and I will investigate. Let me know if there is a sample project you can share that reproduces the issue.
ws...@gmail.com <ws...@gmail.com> #28
Not sure if you still wanted the new bug, but here it is:
gh...@google.com <gh...@google.com> #29
FYI the issue in
And to confirm, lint.do.not.reuse.uast.env
should no longer be needed at all in AGP 7.0+.
ku...@gmail.com <ku...@gmail.com> #30
Thanks #29 . I am noticing that when this happens, after the error log for
package fragment is not found for module:<lintWithKotlin> is a module
There is another error
java.lang.IllegalArgumentException: Argument for @NotNull parameter 'descriptor' of org/jetbrains/kotlin/codegen/context/CodegenContext.intoPackagePart must not be null
at org.jetbrains.kotlin.codegen.context.CodegenContext.$$$reportNull$$$0(CodegenContext.java)
at org.jetbrains.kotlin.codegen.context.CodegenContext.intoPackagePart(CodegenContext.java)
at org.jetbrains.kotlin.asJava.builder.LightClassDataProviderForClassOrObject$computeLightClassData$1$1.invoke(LightClassDataProvider.kt:51)
at org.jetbrains.kotlin.asJava.builder.LightClassDataProviderForClassOrObject$computeLightClassData$1$1.invoke(LightClassDataProvider.kt:38)
at org.jetbrains.kotlin.asJava.builder.LightClassBuilderKt.buildLightClass(LightClassBuilder.kt:64)
at org.jetbrains.kotlin.asJava.builder.LightClassDataProviderForClassOrObject$computeLightClassData$1.invoke(LightClassDataProvider.kt:47)
at org.jetbrains.kotlin.asJava.builder.LightClassDataProviderForClassOrObject$computeLightClassData$1.invoke(LightClassDataProvider.kt:38)
at org.jetbrains.kotlin.cli.jvm.compiler.CliLightClassGenerationSupport.createDataHolderForClass(CliLightClassGenerationSupport.kt:64)
at org.jetbrains.kotlin.asJava.builder.LightClassDataProviderForClassOrObject.computeLightClassData(LightClassDataProvider.kt:45)
at org.jetbrains.kotlin.asJava.builder.LightClassDataProviderForClassOrObject.compute(LightClassDataProvider.kt:61)
at com.intellij.psi.impl.PsiCachedValueImpl.doCompute(PsiCachedValueImpl.java:54)
at com.intellij.util.CachedValueBase.lambda$getValueWithLock$1(CachedValueBase.java:235)
at com.intellij.openapi.util.RecursionManager$1.doPreventingRecursion(RecursionManager.java:113)
at com.intellij.openapi.util.RecursionManager.doPreventingRecursion(RecursionManager.java:72)
at com.intellij.util.CachedValueBase.getValueWithLock(CachedValueBase.java:236)
at com.intellij.psi.impl.PsiCachedValueImpl.getValue(PsiCachedValueImpl.java:43)
at
Does the fix address both of these?
gh...@google.com <gh...@google.com> #31
package fragment is not found
and Argument for @NotNull parameter...
), the workaround in 4.2 is to put
systemProp.lint.do.not.reuse.uast.env=true
in your gradle.properties
file as described in
gh...@google.com <gh...@google.com> #32
Marking fixed in AGP 7.0.
That is, the lint.do.not.reuse.uast.env
workaround should no longer be needed in AGP 7.0+. And, you should no longer see the following warnings/errors while running Lint:
ERROR: package fragment is not found for module:<lintWithKotlin>...
ERROR: Could not generate LightClass for...
java.lang.IllegalArgumentException: Argument for @NotNull parameter 'descriptor' of org/jetbrains/kotlin/codegen/context/CodegenContext.intoPackagePart must not be null
The issue is fixed due to the new "Lint partial analysis" mode (enabled by default) which creates a standalone UastEnvironment
instance for each module, thereby avoiding stale caches in the Kotlin compiler frontend.
Please comment on the bug if you see any similar errors in AGP 7.0+.
Description
AGP: 4.0.0 Kotlin: 1.3.72 JVM: from docker image: 8u252-jdk-slim
Failure happens in CI builds, which always are clean. Failures are random. Sometimes builds are a success, but more often it is not. Each time random classes failed. For example, in this case, failed this little data class:
I included full stacktrace as file