Top-level @service results: field fetchers silently return null for columns the record does not carry (no post-fetch, unlike nested @table fields)

[krhoybraten-sikt]

Summary

Field fetchers for a @table type returned from a top-level @service query field read columns directly off the record the service returned. If the service populated only the key columns, every non-key field resolves to silent null — no warning at build time, no error at runtime. The same shape nested deeper in a service result behaves differently: there, remaining fields are post-fetched in batch through a DataLoader keyed on the primary key, so key-only records work.

The asymmetry itself may be a deliberate contract ("a top-level service owns its record content"), but the failure mode when the contract is broken is the problem: the generated field fetcher quietly returns null for a column the record never carried, for the entire result set. This is the second time this class of defect has reached one of our subgraphs, and both times it survived review because everything compiles and nothing throws.

Minimal repro

Schema (tilgangsstyring subgraph, graphitron 10.0.0-RC33):

type Query {
  tildelbareTilgangskoder: [Tilgangsrolle]
    @service(service: {className: "…Tilgangsroller", method: "tildelbare"})
}

type Tilgangsrolle @table(name: "rolle") {
  kode: String! @field(name: "ROLLEKODE")
  beskrivelse: String
  rolletype: Rolletype
}

Service returns RolleRecords with only ROLLEKODE set (the natural thing to do when a routine yields the key set and the docs elsewhere say remaining fields are fetched from the key):

Result: kode/id correct for all rows; beskrivelse and rolletype are null for all rows (observed: 25/25 in our catalog). The identical Tilgangsrolle shape reached through a nested @table field in a mutation payload resolves all fields, via the generated DataLoader batch fetch.

Expected

One of:

1. Top-level @service results get the same key-based post-fetch as nested @table fields, or
2. A field fetcher that reads a column the returned record does not carry fails loudly — ideally at generation time (the generator knows which columns the field fetchers will read; it could require the service contract to declare them), at minimum at runtime.

Option 2 seems strictly safer: silent null across a whole result set looks exactly like an empty column and ships to production.

Environment

graphitron 10.0.0-RC33 (also inspected the RC34 generated code — same shape), PostgreSQL 18, jOOQ Pro 3.20.11.

[folkef6]

Thanks for this, the diagnosis is right and the failure-mode framing is the useful part. Confirmed against the rewrite generator on trunk, not just RC33/34.

What is happening

The generated root fetcher for a @service returning Result<TableRecord> is a pure passthrough, and the column fields then read straight off whatever the method handed back:

public static Object title(Object source) {
    return ((Record) source).get(Tables.FILM.TITLE);
}

jOOQ's Record.get(Field) returns the unset value rather than complaining, because the column is in the record's row type. Hence a whole column of nulls with nothing thrown.

One correction to the framing

It is not really top-level versus nested. Among root @service fields returning a @table type there are three shapes, and two of them already do what you are asking for:

• polymorphic interface / union return: lifts each record's primary key, re-selects per participant table, builds the payload from the refetched rows
• @discriminate interface return: same
• plain single-table return: passthrough

The first two refetch because they were forced to, one needing the record's Java class as the discriminator and the other a live discriminator column. Both fixtures state the contract in as many words: "set only the PK and leave the rest for Graphitron to fetch, matching the legacy 9.3 contract." The plain return is not forced, so it never got the treatment. That makes this an omission rather than a contract with a rough edge, which is a better reason to change it than "the failure mode is nasty."

We are taking option 1, and unconditionally

Not option 2, for two reasons:

• Generation time cannot see it. Result<RolleRecord> is the same static type whether one column is populated or all of them. The generator would need the service to declare its columns, which is new authoring surface everyone pays for.
• Runtime cannot distinguish it either. jOOQ's touched(Field) counts a field as untouched after a database fetch as well as before it was ever set, so "column the service never populated" and "column that is genuinely NULL" look identical. A check built on it fires on legitimate nulls, which is precisely the ambiguity you flagged.

Unconditional refetch needs no detection and no new declaration, and it collapses the contract to one sentence across all three shapes: populate the key columns, Graphitron fetches the rest. Your reading that "the docs elsewhere say remaining fields are fetched from the key" simply becomes true.

If you do want producer-owned column values

That capability does not disappear. A GraphQL type whose backing class is a jOOQ record but which carries no @table keeps the direct read. So the escape hatch is to drop @table and name the columns with @field(name:), with no change to the Java signature. @table becomes the declaration that the type's column values come from the table.

What to do today on RC33/34

Select every column in the service. That is the current documented contract (handle-services.adoc: "the service is responsible for selecting every column the schema may eventually ask for") and it works.

Also being fixed

The docs page states both record contracts with nothing connecting them: an IMPORTANT block saying a record the framework hands you carries the key columns and nothing else, and a separate section saying a record you hand back must carry every column. You read the first and applied it to the second, which is a mistake the page currently invites.

Tracking

Filed on the rewrite trunk as R834 (the file is deleted when the item ships). Two open questions there where your input would help:

1. Whether per-caller column masking has a home outside @service. Dropping @table to get producer-owned values also costs you @node and global IDs, so if masking is why anyone reaches for the passthrough today, we want to know before closing the door.
2. Keyless @table types will need a build-time rejection, since a refetch has no key to run on. If you have a @table type over a view or a keyless table behind a service, say so and we will size that properly.