Unexpected behavior when using () -> T to break a cycle

[damianw]

If a provision has @Assisted injection parameters and injects a factory function for its own type, the code generated for the factory function unexpectedly ignores the assisted arguments and returns a single instance. For example:

@Inject
class MyDep(
    private val factory: (id: Int) -> MyDep,
    @Assisted val id: Int
) {

    fun next(): MyDep = factory(id + 1)
}

@Component
interface MyComponent {

    val myDepFactory: (id: Int) -> MyDep
}

Produces the following code:

public fun KClass<MyComponent>.create(): MyComponent = InjectMyComponent()

public class InjectMyComponent : MyComponent {
  public override val myDepFactory: Function1<Int, MyDep>
    get() = { arg0 ->
      run {
        lateinit var myDep: MyDep
        MyDep(
          factory = { arg0_ ->
            myDep
          },
          id = arg0
        ).also {
          myDep = it
        }
      }

    }
}

Note that arg0_ is ignored, and the same instance is always returned. In this example, calling next() would return the same instance it was called on. This happens with @Provides in addition to @Inject.

[evant]

Hm, on first glance seems like this is a hole in the loop detection and should cause an error to be thrown. If you don't think it is could you write what code you'd expect to generate? I'm having trouble wrapping my head around it.

[evant]

Update: this would be possible by generating the code below:

public class InjectMyComponent : MyComponent {
    public override val myDepFactory: (id: Int) -> MyDep
        get() = object : Function1<Int, MyDep> {
            override fun invoke(arg0: Int): MyDep {
                return MyDep(this, arg0) 
            }
        }
}

however, this is non-trivial to do. So I'm going to update it to reject assisted injection in cycles and repurpose this ticket to maybe add it in a future release.

[damianw]

@evant Thanks for looking into it, and apologies for the late reply. That seems like a reasonable workaround.

I found however that this problem isn't exclusive to Assisted injection. For example, the following code:

@Inject
class MyDep(
    private val factory: () -> MyDep,
) {

    fun next(): MyDep = factory()
}

@Component
interface MyComponent {

    val myDepFactory: () -> MyDep
}

Also produces unexpected results:

public fun KClass<MyComponent>.create(): MyComponent = InjectMyComponent()

public class InjectMyComponent : MyComponent {
  public override val myDepFactory: Function0<MyDep>
    get() = {
      run {
        lateinit var myDep: MyDep
        MyDep(
          factory = {
            myDep
          }
        ).also {
          myDep = it
        }
      }

    }
}

This case is perhaps a little less cut-and-dry than the Assisted case, but is still kind of unexpected. I would have expected that injecting a () -> MyDep would be the equivalent to the Dagger pattern of injecting a Provider<MyDep>, but that is is not the case.

[evant]

Yes both Lazy<T> and () -> T break cycles in more or less the same way to give you a circular reference. I agree that this can be surprising and probably should be changed.

[damianw]

Gotcha, makes sense. Yeah, arguably the dependency of () -> T is a different dependency than T and thus shouldn't participate in the cycle breaking for T, since it's not really a cycle. The most surprising part of this behavior is that the implementation of () -> T injected is different depending on whether it's part of a "cycle" or not. As it is, it's impossible to inject a factory for an injected type without risking running into this problem. It's made worse by the fact that you may not even notice this issue, leading to some really hard-to-debug issues.

edit: I should say that there is a cycle, just not for T - only () -> T. It could be broken the same way any other cycle is broken:

lateinit var factory: () -> MyDep
factory = { MyDep(factory) }