is there a bug in apollo 5 that does not generate ...

# apollo-kotlin

[agrosner]

is there a bug in apollo 5 that does not generate data builders? default fake resolver is gone too https://www.apollographql.com/docs/kotlin/v5/testing/data-builders#configuring-default-field-values

[mbonnin]

Can you check your test source set?

[mbonnin]

We added the possibility to generate the sources in there

[mbonnin]

Because it makes more sense

[mbonnin]

See https://github.com/apollographql/apollo-kotlin/issues/5257

[agrosner]

ok ill build tests, i had one production usage of the builder I was able to fix. but BaseFakeResolver != DefaultFakeResolver where I could pass __Schema.all what is the replacement now?

[agrosner]

also this doc is wrong then:

/**
   * Overrides the way the generated data builders are connected.
   * Use this if you want to connect the generated models to another task than the default destination.
   *
   * By default, the generated sources are connected to:
   * - main sourceSet for Kotlin projects
   * - commonMain sourceSet for Kotlin multiplatform projects
   * - main sourceSet for Android projects
   */
  fun dataBuildersOutputDirConnection(action: Action<in DirectoryConnection>)

since its connected to only test directories now

[mbonnin]

Yup, that doc is 100% wrong, I'll fix in in a bit

[mbonnin]

but BaseFakeResolver != DefaultFakeResolver where I could pass __Schema.all what is the replacement now?

Looking into this

[agrosner]

thanks . ive also tried connecting the data builder to main source via:

dataBuildersOutputDirConnection { 
  connectToAllAndroidVariants()
}

however the task

> Task :infra-apollo-schema:generateStorefrontDataBuildersApolloSources

is taking serveral minutes to run / not completing

[mbonnin]

Mmm that's not good

[mbonnin]

Can you hook a debugger and see where it's stuck?

[agrosner]

it completed

:infra-apollo-schema:generateStorefrontDataBuildersApolloSources | 13M43S | 46% | ████████████████████████████████████████████████████████████████████████████████

13 minutes 😖

[mbonnin]

I'm assuming it was faster before, right?

[agrosner]

and the generated code is still only in unit test directory

[agrosner]

Screenshot 2025-11-06 at 3.28.11 PM.png

[mbonnin]

I think this is an IDE issue

[mbonnin]

The sources are generated only once but wired to all the variants

[mbonnin]

And IJ/AS can only display one variant at a time (unitTest here)

[mbonnin]

Back to this:

> but BaseFakeResolver != DefaultFakeResolver where I could pass __Schema.all what is the replacement now?

Trying to understand. Do you need to actively pass __Schema.all? If you extend DefaultFakeResolver() it should work. One example is here: https://github.com/apollographql/apollo-kotlin/blob/e994e2fb9eee52356c177f4bff55b8[…]ts/data-builders-kotlin/src/test/kotlin/test/DataBuilderTest.kt

[agrosner]

ah i see. if thats true, then its showing up as red in the IDE and non autocompletable.

[agrosner]

Trying to understand. Do you need to actively pass __Schema.all?  If you extend DefaultFakeResolver() it should work. One example is here:

is this now code generated? previously wasnt

[agrosner]

ah thats why

[mbonnin]

Yes, I'm trying to steer people away from using __Schema types. We added a bunch of stuff there over the year but never really thought it through

[agrosner]

and its not autocompletable since the usage of it is in a main source set (testing module)

[agrosner]

is there a way to unwire what the plugin was doing in terms of connecting to unit test directory, and just connecting to a single one? since I want the IDE to autocomplete, if i could do:

dataBuildersOutputDirConnection {
   resetConnection()
   connectToAndroidSourceSet("main")
}

then id get IDE autocomplete

[agrosner]

we use the main source set for mocking behind code logic in debug source set, using the data builders to make it easier to construct them

[mbonnin]

If you set dataBuildersOutputDirConnection{} this is what it is doing

[agrosner]

oooo

[mbonnin]

It disables the default wiring

[agrosner]

ok so i just set it to main oncee, i was doing all source sets

[mbonnin]

Yes

[agrosner]

🤌👍

[mbonnin]

But Android "SourceSet" are weird. AGP really wants you to thing in terms of "components" now

[mbonnin]

Are you using AGP9?

[agrosner]

not yet 8.11.1

[mbonnin]

Good 🙂

[mbonnin]

we use the main source set for mocking behind code logic in debug source set, using the data builders to make it easier to construct them

I'm not sure I follow 100% here

[mbonnin]

At the end of the day, you have several "variants":
• debug
• release
• unitTest
• androidTest (IIRC)

[mbonnin]

Do you need the data builders in all the variants? Because this is what connectToAndroidSourceSet("main") should be doing. But AGP doesn't really want us to do this, I can't really remember why

[agrosner]

sure. we have a testing module that exposes a fake resolver that applies custom logic for scalar adapters. its in main source set. then debug source set files in other modules declare a modk data operation in the network transport layer to return it instead:

@ContributesTo(AppScope::class)
@Module
object ImmersiveCategoryMockModule {

    @Provides
    @IntoMap
    @MockOperationKey(GetCategoryBlockBuilderQuery::class)
    fun mockICPQuery(): MockOperation<*> = MockDataOperation(
        handlesRequest = { op: GetCategoryBlockBuilderQuery -> op.categoryId == "0" },
    ) { resolver, _ ->
        GetCategoryBlockBuilderQuery.Data(resolver = resolver) {
            blockBuilderCategoryExperience = buildBlockBuilderCategoryExperience {
                blocks = listOf(
                    buildBlockBuilderConfidenceBar { },
                    buildBlockBuilderGuide { },
                    buildBlockBuilderBanner { },
                    buildBlockBuilderBuyingGuideRow { },
                    buildBlockBuilderCardRow { },
                    buildBlockBuilderFreeShippingBanner { },
                )
            }
        }
    }
}

[agrosner]

At the end of the day, you have several "variants":

• debug

• release

• unitTest

• androidTest (IIRC)

[3:41 PM]

Do you need the data builders in all the variants? Because this is what connectToAndroidSourceSet("main") should be doing. But AGP doesn't really want us to do this, I can't really remember why

yeah thats why it probably took a long time to compile. but interesting AGP doesnt want us to do this...

[mbonnin]

we have a testing module that exposes a fake resolver that applies custom logic for scalar adapters. its in main source set

Could you make this a non-android plain JVM module? Variants + libraries are adding a lot of complexity

[mbonnin]

Re: time. I don't think it depends on the number of variants. If the slow task is generateFooDataBuilderSources then it should be called only once for all variants.

[agrosner]

yeah its much slower than in 4.x. youre right - makes sense now that it only is called once