@semanticNonNullField does not force non-nullable Kotlin type for nullable schema fields

[yt8492]

Version

5.0.0-alpha.2

Summary

I am migrating from the deprecated @nonnull directive to the new nullability spec directives in Apollo Kotlin v5, as described in the official documentation: Migrate from @nonnull.

The issue is that when applying @semanticNonNullField to a field that is explicitly nullable in the GraphQL schema, the generated Kotlin property remains nullable, which is not the expected behavior for a directive designed to override semantic nullability.

This is my example repository. You can reproduce this problem.
https://github.com/yt8492/ApolloPlayground

Steps to reproduce the behavior

1. Define the GraphQL Schema:

schema {
    query: Query
}

type Query {
    foo: Foo!
}

type Foo {
    id: ID!
    bar: Bar # Nullable in the schema
}

type Bar {
    id: ID!
}

2. Define extra.graphqls to enforce non-nullability for Foo.bar:

extend schema @link(
    url: "[https://specs.apollo.dev/nullability/v0.4](https://specs.apollo.dev/nullability/v0.4)",
    import: ["@semanticNonNull", "@semanticNonNullField", "@catch", "CatchTo", "@catchByDefault"]
)
# Applying a default catch strategy for completeness, though not strictly required for this specific issue.
extend schema @catchByDefault(to: NULL)

# Attempt to make the schema-nullable field 'bar' semantically non-null
extend type Foo @semanticNonNullField(name: "bar")

3. Define a sample Query:

query ExampleQuery {
    foo {
        id
        bar {
            id
        }
    }
}

4. Observe the Generated Kotlin Code:

In the generated Kotlin data class for the query, the bar property is of type Bar?, despite the @semanticNonNullField directive.

public data class Foo(
  public val id: String,
  public val bar: Bar?,
)

5. Usage demonstrating the issue:

The code still requires a safe call (?.) on bar, confirming it is nullable:

fun main(): Unit = runBlocking {
  val apollo = ApolloClient.Builder().build()
  apollo.query(ExampleQuery())
    .execute()
    .dataOrThrow()
    .foo
    .bar
    ?.id // The 'bar' property is still nullable, requiring the safe call.
}

Logs

No response

[martinbonnin]

Hi 👋

Thanks for reaching out! You will need to use extend schema @catchByDefault(to: THROW) to rip the benefits of @semanticNonNull. @catchByDefault(to: NULL) preserves the current default meaning that errors are modelled as null. This is meant for existing apps that do not want a breaking change.

If you have a new app, use @catchByDefault(to: THROW) to opt-in the new non-null behaviour on all fields.

[yt8492]

Thank you. Let me confirm my understanding.

With the previous @nonnull directive, such as:

extend type Foo @nonnull(fields: "bar")

It would throw an error if the field was actually null at runtime.

With the new @semanticNonNull system, the handling of this runtime null value is now controlled by @catchByDefault. To achieve the same "throw error" behavior as the old @nonnull, I must specify @catchByDefault(to: THROW), correct?

Thank you very much for your help!

[yt8492]

I'm sorry, I have one more question.

The documentation states that we can specify non-null behavior at the query field level using @catch(to: THROW), but the resulting Kotlin type is still nullable.

Here is my extra.graphqls and query. What is the problem?

extend schema @link(
    url: "https://specs.apollo.dev/nullability/v0.4",
    import: ["@semanticNonNull", "@semanticNonNullField", "@catch", "CatchTo", "@catchByDefault"]
)
extend schema @catchByDefault(to: THROW)
extend type Query @semanticNonNullField(name: "bar")

query ExampleQuery {
    foo {
        id
        bar @catch(to: THROW) {
            id
        }
    }
}

fun main(): Unit = runBlocking {
  val apollo = ApolloClient.Builder().build()
  apollo.query(ExampleQuery())
    .execute()
    .dataOrThrow()
    .foo
    .bar
    ?.id // bar is @catch(to: THROW) filed but this bar is nullable
}