Resources_Delegate.initSystem called twice before disposeSystem was called

[hardysim]

I get the following error sometimes (a retry works sometimes and sometimes it's working directly) when running the verify-command on paparazzi 1.0.0:

com.example.ExampleTest > test_ExamplePreview FAILED
    java.lang.AssertionError: Resources_Delegate.initSystem called twice before disposeSystem was called
        at android.content.res.Resources_Delegate.initSystem(Resources_Delegate.java:86)
        at com.android.layoutlib.bridge.android.BridgeContext.initResources(BridgeContext.java:299)
        at com.android.layoutlib.bridge.impl.RenderAction.setUp(RenderAction.java:259)
        at com.android.layoutlib.bridge.impl.RenderAction.init(RenderAction.java:151)
        at com.android.layoutlib.bridge.impl.RenderSessionImpl.init(RenderSessionImpl.java:194)
        at app.cash.paparazzi.Paparazzi.prepare(Paparazzi.kt:172)
        at app.cash.paparazzi.Paparazzi$apply$statement$1.evaluate(Paparazzi.kt:122)
        at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
        at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
        at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
        at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
        at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
        at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
        at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
        at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
        at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
        at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
        at jdk.internal.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
        at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
        at com.sun.proxy.$Proxy5.processTestClass(Unknown Source)
        at org.gradle.api.internal.tasks.testing.worker.TestWorker$2.run(TestWorker.java:176)
        at org.gradle.api.internal.tasks.testing.worker.TestWorker.executeAndMaintainThreadName(TestWorker.java:129)
        at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:100)
        at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:60)
        at org.gradle.process.internal.worker.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:56)
        at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:133)
        at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:71)
        at worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:69)
        at worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:74)

I'm using a PreviewParameterProvider and for such previews, I'm running snapshot() multiple times in a loop (adding a name-suffix for each golden image). I have a feeling, that this error started showing up once I've added this. But since it's working fine sometimes this might be a timing issue? Any ideas?

[fcduarte]

@hardysim hey, we recently updated layoutlib to 2021.2.1-patch1, could you try to run your code with the snapshot and see if it's still happening?

[brudaswen]

I tried adding this patch-version of layoutlib as a dependency. But the error still occurs.

[jrodbx]

@hardysim @brudaswen can you provide a minimal sample? would help us diagnose the issue much faster!

[brudaswen]

I will try to figure out why one of our tests is running into this issue. Maybe I can narrow it down. Thanks for your help.

[andersu]

I had the same error and in my case it looks like it was caused by the file I was testing not having a package name that matched the folder it was in. It must have not been updated when I moved the file out of the app module. So after this change the Resources_Delegate.initSystem called twice before disposeSystem was called went away:

Might not be the same bug that the others are experiencing, but maybe it helps someone.

[jrodbx]

Thanks @andersu for that helpful tip!

I'm closing this since it seems like a test setup issue vs a paparazzi issue.

[hardysim]

I double checked our namespace and it's matching the folder name (and the name of the composable to be tested). It's still happening. Maybe @brudaswen has some more ideas? But I think this is still an issue and should be reopened.

[elihart]

We are also seeing this sporadically on CI with 1.1.0. It seems like if it was a namespace issue it wouldn't be spurious, and it doesn't seem like this should be closed

[ashley-figueira]

For us this happened because one of our screens that we were testing with paparazzi had a LottieAnimation composable and it was causing this exact issue.

[elihart]

The problem also turned out to be Lottie for us 😓 thanks for the tip @ashley-figueira !

It seems like if there is a crash in the composable UI then it might break some internal state of Paparazzi, resulting in this downstream error