Looks like migrating from `arrow.fx.coroutines.Schedule` to `arrow.resilience.Schedule` might be cau...

# arrow

[Sam Pengilly]

Looks like migrating from arrow.fx.coroutines.Schedule to arrow.resilience.Schedule might be causing issues with kapt. After the change I'm getting a "Bad class file: <filepath>, undeclared type variable: Input" error, despite all the code looking correct and the only changes being import statements. Anyone else experienced this?

[simon.vergauwen]

kapt 😭 Any code you can share? This is probably similar to an issue we saw before with a bug in the kapt compiler.

[simon.vergauwen]

cc\\ @Alejandro Serrano Mena

[Sam Pengilly]

import arrow.core.Either
import arrow.resilience.Schedule
import com.apollographql.apollo3.api.Error
import com.apollographql.apollo3.api.Query
import kotlin.time.Duration.Companion.milliseconds

interface MyClient {

    suspend fun <D : Query.Data, T> executeQuery(
        query: Query<D>,
        networkRetryPolicy: Schedule<Throwable, *> = DefaultNetworkRetryPolicy,
        parse: (data: D?, errors: List<Error>?) -> Either<Throwable, T>
    ): Either<Throwable, T>

    companion object {
        val DefaultNetworkRetryPolicy = Schedule
            .exponential<Throwable>(10.milliseconds)
            .andThen(Schedule.recurs(3))
    }

}

Provided using Dagger:

@Module
@InstallIn(SingletonComponent::class)
class ApiModule {

    @Provides
    fun provideMyClient(config: MyConfig): MyClient =
        MyClientImplementation(buildApolloClient(config))

}

internal class MyClientImplementation(private val apolloClient: ApolloClient) : MyClient {
    override suspend fun <D : Query.Data, T> executeQuery(
        query: Query<D>,
        networkRetryPolicy: Schedule<Throwable, *>,
        parse: (data: D?, errors: List<Error>?) -> Either<Throwable, T>
    ): Either<Throwable, T> = either {
        val apolloResponse = Either.catch {
            networkRetryPolicy.retry { apolloClient.query(query).execute() }
        }.bind()

        parse(apolloResponse.data, apolloResponse.errors).bind()
    }
}

[Sam Pengilly]

building to get the full error now

[Sam Pengilly]

/my/repository/folder/build/tmp/kapt3/stubs/my/package/ClassThatInjectsMyClientWithDagger.java:17: error: cannot access MyClient
    public my.package.MyClient client;
                     ^
  bad class file: /my/repository/folder/build/libs/my-module.jar(/my/package/MyClient.class)
    undeclared type variable: Input
    Please remove or make sure it appears in the correct subdirectory of the classpath.

Tried to keep the names consistent but stripped down and not tied to the concepts of my system

[Alejandro Serrano Mena]

yep, that’s the same error 😕

[Alejandro Serrano Mena]

one question: could you by any chance send us the decompiled version of DefaultNetworkRetryPolicy? I use JD GUI to get it; that way we can inspect where the non-bound variable comes from

[Alejandro Serrano Mena]

(I’m happy to take this into a DM if you prefer not exposing more things in this thread)

[Sam Pengilly]

Here's the DefaultNetworkRetryPolicy bit decompiled:

@NotNull
public final Function2<Input, Continuation<? super Schedule.Decision<? super Input, ? extends Output>>, Object> getDefaultNetworkRetryPolicy-k5utPk0() {
  return DefaultNetworkRetryPolicy;
}
    
@NotNull
private static final Function2<Input, Continuation<? super Schedule.Decision<? super Input, ? extends Output>>, Object> DefaultNetworkRetryPolicy = Schedule.andThen-GI_V1oY(Schedule.Companion.exponential-la_RjoE$default(Schedule.Companion, DurationKt.toDuration(10, DurationUnit.MILLISECONDS), 0.0D, 2, null), Schedule.Companion.recurs-ZhmCDx4(3L));

[Sam Pengilly]

The only bit of configuration we do for kapt in the build is this workaround:

// KAPT seems to not honour the JVM target specified in Kotlin options sometimes
// <https://youtrack.jetbrains.com/issue/KT-55947/Unable-to-set-kapt-jvm-target-version>
tasks.withType(KaptGenerateStubsTask::class.java).configureEach {
    kotlinOptions.jvmTarget = JavaVersion.VERSION_1_8.toString()
}

[Alejandro Serrano Mena]

I think the problem may be there, because Input seems to be introduced without declaring it before…

[Alejandro Serrano Mena]

if you give a explicit type in the Kotlin code, does it help?

[Sam Pengilly]

On the recurs call?

[Sam Pengilly]

Or on the variable itself?

[Sam Pengilly]

I'll give it a go when I'm back in front of that code on Monday.

[Alejandro Serrano Mena]

on DefaultNetworkRetryPolicy

[Sam Pengilly]

Yep, looks like adding the explicit return type resolves the kapt issue:

val DefaultNetworkRetryPolicy: Schedule<Throwable, Either<Duration, Long>> = Schedule
    .exponential<Throwable>(10.milliseconds)
    .andThen(Schedule.recurs(3))

[Sam Pengilly]

actually nevermind, I spoke too soon. I had a build pass but it was a build that didn't include the kapt step for some reason. It's still failing

[Sam Pengilly]

Changing the wildcard type parameter in this function definition also didn't help:

suspend fun <D : Query.Data, T> executeQuery(
    query: Query<D>,
    networkRetryPolicy: Schedule<Throwable, Either<Duration, Long>> = DefaultNetworkRetryPolicy,
    parse: (data: D?, errors: List<Error>?) -> Either<Throwable, T>
): Either<Throwable, T>