Workmanager library can't resolve WorkerParameters

Describe the bug When the application tries to launch a particular worker in my closed source project the application crashes.

Caused by: org.koin.core.error.NoBeanDefFoundException: No definition found for class:‘androidx.work.WorkerParameters’. Check your definitions!

Subsequent launches of the same app will crash immediately when the app opens, with same error message, even if we don’t try to start any work. That’s because the work previously scheduled is trying to run as soon as the application starts.

Depending on how the work is scheduled it will also crash the application repeatedly, even if it’s not launched by user/debugger.

To Reproduce

Still under investigation.

One way to trigger the bug is changing the order of the constructor parameters on ListenableWorker. Then it happens at the moment the work is scheduled to start.

For example, in my project (closed source)

THIS worked code A:

class NewsDownloadWorker(
    context: Context,
    private val params: WorkerParameters,
    webService: WebService,
    private val settingsDao: RemoteTabDao,
    appDatabase: AppDatabase,
    workerTracker: WorkerTracker
)

while THIS failed

code B:

class NewsDownloadWorker(
    context: Context,
    webService: WebService,
    private val settingsDao: RemoteTabDao,
    appDatabase: AppDatabase,
    private val params: WorkerParameters,
    workerTracker: WorkerTracker
)

May be related to https://github.com/InsertKoinIO/koin/issues/988. Following the suggestions there, I found out that using named paramers I can work around the issue even when ‘‘code B’’ is used. This is the original dsl declaration:

code 1:

  worker {
            NewsDownloadWorker(
               get(),
               get(),
                 get(),
                 get(),
               get(),
              get()
            )
        } 

this is the workaround I found:

code 2:

  worker {
            NewsDownloadWorker(
                context = get(),
                params = get(),
                webService = get(),
                settingsDao = get(),
                appDatabase = get(),
                workerTracker = get()
            )
        } 

and this is the opposite of the workaround, meaning it will make it always fail: code 3:

  worker {
            NewsDownloadWorker(
                context = get(),
                webService = get(),
                settingsDao = get(),
                appDatabase = get(),
                params = get(),
                workerTracker = get()
            )
        } 

In short:

• code A+1 works, but B+1 fails

• code A+2 and B+2 both work (making code 2 a workaround)

• code A+3 surprisingly fails - constructor in ideal order but dsl in “bad” order

• code B+3 fails as expected - both constructor and dsl are in “bad” order

The interesting take away is that, no matter how NewsDownloadWorker constructor order, we can make it or break it by the order of parameters inside worker dsl.

Given more time I’ll do some testing in the koin project itself and use it as a unit/integration test.

Koin project used and used version (please complete the following information): koin-androidx-workmanager version 2.2.2

Mitigation Even when the source of this problem is found and solved I’d suggest wrapping the work manager factory code in a try catch to avoid crashing the app.

The main reason is that once the work is scheduled (and depending on the work constraints, such as periodic, internet availability etc) the app may crash immediately when launched, as well as repeated times when it’s not on the foreground.

[Alexs784]

I am on Koin 3.1.6 and I am also having the same exact issue mentioned in the original issue. I am now trying to used named parameters (I can’t reproduce the issue, the only way is to ship a new build and look at the crash reporting tool I guess hoping the number goes down 🤞 )

[wax911]

Graph resolution should help you resolve parameters: https://github.com/InsertKoinIO/koin/blob/master/docs/reference/koin-core/injection-parameters.md

Thanks for the heads up, so far this seems to have solved the issue for me atleast, I will do more testing and report back. Also out of context but maybe it’s nothing big, but I was running v2.2.2 (prior 2.2.1) but I got a lot of GlobalContext._koin leaks on modules that scope other modules, so I reverted back to v2.2.1.

Thanks again!