`@nodeId` lookup argument on a multitable-interface-returning field binds to a single implementation instead of dispatching on the id's typeId

[krhoybraten-sikt]

Summary

A by-id lookup field returning a multitable interface compiles without
warnings, but at runtime the @nodeId argument turns out to be bound to ONE
implementing type — ids of the other implementations are rejected.

type Query {
  applikasjon(id: ID! @nodeId): Applikasjon
}

interface Applikasjon implements Node { … }

type FeideApplikasjon implements Applikasjon & Node
    @table(name: "feide_applikasjon") @node(typeId: "20012", keyColumns: ["SUBJEKT_ID"]) { … }
type MaskinportenApplikasjon implements Applikasjon & Node
    @table(name: "maskinporten_applikasjon") @node(typeId: "20013", keyColumns: ["SUBJEKT_ID"]) { … }
type MaskinbrukerApplikasjon implements Applikasjon & Node
    @table(name: "maskinbruker_applikasjon") @node(typeId: "20011", keyColumns: ["SUBJEKT_ID"]) { … }

Querying with a MaskinbrukerApplikasjon-id:

{ applikasjon(id: "MjAwMTE6LTE2") { __typename navn } }

{"data":{"applikasjon":null},"errors":[{"message":"Invalid node id \"MjAwMTE6LTE2\"
for this argument: decodes to type \"20011\", expected a FeideApplikasjon id", …}]}

The implicit binding appears to pick one implementing type (here
FeideApplikasjon); only that type's ids work.

Expected behaviour

Since the node-id itself carries the typeId, a lookup returning the interface
could dispatch to the matching implementation's table (same information the
generated internal node-resolver uses). Alternatively, if interface-returning
@nodeId lookups are unsupported, an author-error at generate time — the
silent single-type binding compiles clean and fails only at runtime, per-id.

Workaround

One lookup query per implementing type
(feideApplikasjon(id: ID! @nodeId(typeName: "FeideApplikasjon")) etc.);
callers pick the query from the id's typeId prefix, or use the supergraph-level
node(id) where the node-subgraph is composed.

Version: 10.0.0-RC30

[folkef6]

https://graphitron.sikt.no/roadmap/plans/nodeid-arg-dispatches-on-typeid.html

[krhoybraten-sikt]

Thanks — R673 looks right for the root-field case, and the dispatch-with-field-level-guard design (each branch validating its own typeIds, a clear error naming the candidate types on miss) is exactly what we hoped for.

One scoping question, since R673 explicitly lists child multitable fields and payloads as out of scope: is that intended as "later phase of the same effort", or should we file those separately?

Our concrete downstream cases, in priority order:

1. Payload fields returning the interface. Our mutation payloads currently expose three typed lists (feideApplikasjoner / maskinbrukerApplikasjoner / maskinportenApplikasjoner) purely because a single applikasjoner: [Applikasjon] field binds to one implementation. Every consumer stitches the three lists back together client-side. R673's root-field fix doesn't reach these.

2. Child fields for polymorphic audit references. Our tracking columns split actors into a person leg (FK to one table — works fine as a plain @reference) and an application leg (FK to a supertype table with three implementing subtypes). Exposing opprettetAvApplikasjon: Applikasjon as a child field needs the same per-implementation dispatch, just driven by the FK row's subtype rather than an id argument's typeId.

If these belong in R673's later phases, a note on the plan page would let us plan against it; if they need their own issue, we'll write one with minimal repros for both shapes.

[krhoybraten-sikt]

Following up on the scoping question above — it's been a few days and the answer decides how we cut our first beta contract, so a quick signal either way would help us.

If "file separately" is the answer, we'll open a dedicated issue for the payload case with a minimal repro (the three-typed-lists workaround from the issue text is now present on several mutation payloads, and each new mutation copies it). If it's "later phase of R673", a note on the plan page saying so is all we need — we'll shape the contract accordingly (keep the three lists, add the interface field additively when it lands).

For prioritisation: the payload case has grown since we asked — every batch mutation over the application hierarchy now carries three parallel lists that every consumer stitches back together client-side, and the shape is about to be frozen into a published contract with a deprecation-period cost attached to undoing it.

[folkef6]

Sorry for the slow answer on the scoping question; here it is, together with the reasoning, so you can cut the contract with full information.

Short version: separate filings, not later phases of R673. R673 shipped today (10-SNAPSHOT trunk). The two downstream cases are deliberately not phases of it, and the reason is one line: R673's defect was that a @nodeid argument's expected node type was baked into each branch as a generation-time constant. Neither of your cases carries a @nodeid argument; in both, branch selection is driven by the FK correlation, not by a decoded id. So nothing in R673's implementation changes either case whichever way it landed, and pretending they're phases of it would just hide two independent pieces of work behind one id.

Where each case actually stands:

1. Payload fields returning the interface (applikasjoner: [Applikasjon] instead of three typed lists). Nothing on the roadmap covers this today, and we'd like a minimal repro before filing, because the repro decides which kind of item it is. A payload type is class-backed, and a polymorphic-returning field on a class-backed parent is already a classified shape in the generator, so your schema may be reaching that path and misbehaving (a bug filing) rather than falling through to single-implementation binding by design (a capability filing). If you can share the mutation + payload SDL and what gets generated, we'll file it on the right side of that line.

2. Child fields for polymorphic audit references (opprettetAvApplikasjon: Applikasjon, FK toward a supertype table with three subtypes). This should already work at single cardinality on a current build: single-valued multi-table polymorphic child fields classify on both table-backed and class-backed parents, and where the join path from the parent to each implementing subtype can't be auto-discovered, @referenceFor(type: ..., path: ...) is the surface for stating a per-participant path (participants you don't name keep automatic discovery). Please try it on a current build; if it still binds to one implementation or rejects, that's a child-field classifier bug and we want it as its own issue with the SDL.

One known gap in that area, already tracked: the batched (list/connection) forms of parent-holds-FK correlation reject at build time by design until the correlation-column plumbing lands. A single-valued field like your audit reference is not affected by that gap.

So, concretely: send the payload repro here or in a fresh issue and we'll file the item; try @referenceFor on the audit reference and file separately only if it misbehaves.

[krhoybraten-sikt]

Here is the payload repro you asked for, plus the result of trying @referenceFor on the audit reference.

Version caveat: everything below is 10.0.0-RC35, which is what our subgraph pins. R673 shipped to trunk after RC35, so if your current build is newer, treat this as RC35 status rather than the last word — particularly the classification questions, which a later build may already answer differently.

Short version: case 1 (payload field) reaches the classified path and misbehaves at runtime — bug side of your line, and the defect is a one-line omission in the generated fetcher. Case 2 (polymorphic audit child field) works, runtime-verified across two implementations; nothing to file.

---

1. Payload field returning the interface — reaches the path, then breaks at runtime

Schema

type Mutation {
  deaktiverApplikasjoner(
    input: [DeaktiverApplikasjonerInput!]!
  ): DeaktiverApplikasjonerPayload
    @service(service: {className: "...ApplikasjonStatusService", method: "deaktiverApplikasjoner"})
}

type DeaktiverApplikasjonerPayload {
  applikasjoner: [Applikasjon]
    @referenceFor(type: "FeideApplikasjon",        path: [{key: "fk_feide_applikasjon_subjekt_id"}])
    @referenceFor(type: "MaskinportenApplikasjon", path: [{key: "fk_maskinporten_applikasjon_subjekt_id"}])
    @referenceFor(type: "MaskinbrukerApplikasjon", path: [{key: "fk_maskinbruker_applikasjon_subjekt_id"}])
  errors: [DeaktiverApplikasjonerError]
}

union DeaktiverApplikasjonerError = ApplikasjonIkkeFunnet | ManglerSkrivetilgang

Applikasjon is the same multitable interface as in the issue text: three @table implementations, each keyed on SUBJEKT_ID, all sharing an FK to a hub table subjekt.

The backing payload class exposes the hub accessor the classifier asks for:

public class DeaktiverApplikasjonerPayload {
    private List<SubjektRecord> applikasjoner = new ArrayList<>();
    private List errors;
    public List<SubjektRecord> getApplikasjoner() { return applikasjoner; }
    // + setter
}

Getting there — the diagnostics were good

Three build iterations, each with an actionable message:

1. Bare applikasjoner: [Applikasjon] against the original three-typed-lists POJO:

   polymorphic child field 'applikasjoner' on a free-form record-backed parent (Pojo / JavaRecord) requires a typed accessor to discover the hub table the polymorphic participants share an FK to. Either expose a typed accessor on the parent returning '...HubRecord' ... Note: @sourceRow is not yet supported for polymorphic returns.

2. After adding List<SubjektRecord> getApplikasjoner() — per-participant FK ambiguity, correctly naming all five candidate FKs per participant and pointing at @referenceFor.

3. With @referenceFor naming our real composite identity FK fk_<t>_applikasjon_subjekt (subjekt_id, subjekt_type) — the [deferred] diagnostic, which is your already-tracked gap:

   participant 'FeideApplikasjon' correlates through a foreign key held on the parent/hub table 'subjekt' (parent-side column(s) subjekt_type outside its primary key). A parent-holds-FK participant is single-valued ..., so it is served at single cardinality; batching it through the DataLoader key is not yet supported.

   That is exactly the batched parent-holds-FK gap you flagged, and the severity class [deferred] vs [author-error] made it easy to tell "known gap" from "you did it wrong" — that distinction is genuinely useful, thanks.

   Sidestepping it is cheap on our side: a redundant single-column FK participant.subjekt_id -> subjekt.subjekt_id makes the correlation participant-holds-FK, and then it generates. That is what the SDL above uses.

It generates real dispatch

With that, generation succeeds and emits exactly what we hoped for — a UNION ALL discriminator stage over the three participant tables emitting __typename + PK, then one projection query per present type, restricted to that type's inline-fragment selection, DataLoader-batched. No single-implementation binding anywhere. The generated shape is right.

But every request throws

Exception while fetching data (/deaktiverApplikasjoner/applikasjoner) :
class ...generated.graphitron.schema.Outcome$Success cannot be cast to
class ...tilgangsstyring_service.records.DeaktiverApplikasjonerPayload

and on the error arm:

class ...generated.graphitron.schema.Outcome$ErrorList cannot be cast to
class ...tilgangsstyring_service.records.DeaktiverApplikasjonerPayload

Both arms, every request.

The defect

The polymorphic child-field path never emits the Outcome arm-unwrapping that the monomorphic path emits. Same payload type, same errors sibling, two generated fetchers:

Monomorphic sibling field (correct):

if (!(env.getSource() instanceof Outcome.Success<?> success)) {
    return CompletableFuture.completedFuture(null);
}
...
Iterable<FeideApplikasjonRecord> elements =
    ((OpprettFeideApplikasjonerPayload) success.value()).getApplikasjoner();

Polymorphic field (broken):

Iterable<SubjektRecord> elements =
    ((DeaktiverApplikasjonerPayload) env.getSource()).getApplikasjoner();

env.getSource() is the Outcome wrapper whenever the payload carries a WrapperArm errors field, so the unguarded cast cannot succeed.

Note the emitted code is byte-identical whether or not the payload has an errors field — the polymorphic path simply never considers the wrapper. It happens to be correct only when no WrapperArm transport is in play.

Isolating control

Delete errors from the payload, change nothing else, and the same schema works. A batch deactivating one FeideApplikasjon and one MaskinbrukerApplikasjon in one call returns:

__typename = [FeideApplikasjon, MaskinbrukerApplikasjon]

Correct per-implementation dispatch at list cardinality. So the classifier, the @referenceFor paths, the discriminator query and the per-type projections are all correct; the only thing wrong is the missing arm unwrap.

The single-valued variant (applikasjon: Applikasjon with a SubjektRecord getApplikasjon() accessor) generates the same unguarded cast:

Record parentRecord = ((DeaktiverApplikasjonerPayload) env.getSource()).getApplikasjon();

so it should be affected identically; we runtime-verified the list form.

Which side of the line

Bug, not capability: the shape classifies, generates correct dispatch SQL, and demonstrably works once the wrapper is removed. Happy to move this to a fresh issue if you would rather track it separately.

---

2. Polymorphic audit child field with @referenceFor — works

Reported as agreed, since it did not misbehave: nothing filed.

On a @table-backed parent, the audit reference dispatches correctly. Plain @reference is refused first, with a message that says precisely why and what to use instead:

an explicit @reference is not supported on a multi-table interface/union child field. Per-participant join paths are auto-discovered ...; a field-level @reference applies one stated path to every participant, so it can be terminal-correct for at most one and cannot express a distinct join per participant. Remove the @reference directive and, where auto-discovery is insufficient, state a per-participant path with @referenceFor.

With per-participant paths — two hops each, parent FK to the hub, then hub to the participant:

type FeideApplikasjon implements Applikasjon & Node
    @table(name: "feide_applikasjon")
    @node(typeId: "20012", keyColumns: ["SUBJEKT_ID"]) {
  opprettetAvApplikasjon: Applikasjon
    @referenceFor(type: "FeideApplikasjon", path: [
      {key: "feide_applikasjon__fk_feide_applikasjon_opprettet_av_applikasjon"},
      {key: "feide_applikasjon__fk_feide_applikasjon_subjekt"}])
    @referenceFor(type: "MaskinportenApplikasjon", path: [
      {key: "feide_applikasjon__fk_feide_applikasjon_opprettet_av_applikasjon"},
      {key: "maskinporten_applikasjon__fk_maskinporten_applikasjon_subjekt"}])
    @referenceFor(type: "MaskinbrukerApplikasjon", path: [
      {key: "feide_applikasjon__fk_feide_applikasjon_opprettet_av_applikasjon"},
      {key: "maskinbruker_applikasjon__fk_maskinbruker_applikasjon_subjekt"}])
}

Runtime, with two rows whose opprettet_av_applikasjon points at actors of different types:

skriv-it-feideapp-2 -> opprettetAvApplikasjon = {__typename: FeideApplikasjon,        navn: skriv-it-statusapp}
skriv-it-feideapp   -> opprettetAvApplikasjon = {__typename: MaskinbrukerApplikasjon, navn: skriv-it-adminbruker}

Both implementations dispatched correctly in one query, including the self-referencing participant where the parent's own table is also a participant. Rows whose actor is a hub row belonging to no participant table (our system subject) correctly resolve to null.

This is the case we had assumed was blocked, so it unblocks the audit-reference work outright. Thanks for pointing at the directive.

[folkef6]

Thanks for the repro; it was precise enough to land on the first attempt. Filed as R873: https://graphitron.sikt.no/roadmap/plans/outcome-payload-polymorphic-child-arm-unwrap.html (Backlog; the page appears once the next trunk docs deploy runs).

Your RC35 finding reproduces on current trunk, after R673. So this is not something the @nodeId work changed either way, and your diagnosis holds as written: it is the bug side of the line, and it is the missing arm unwrap.

Three things we confirmed while reproducing, all matching what you reported:

1. Generating from SDL where one wrapper payload carries both a monomorphic and a polymorphic child field puts the defect and its control in the same emitted class. The monomorphic sibling narrows Outcome.Success and reads off success.value(); the polymorphic field, same payload, same class, reads ((Record) env.getSource()).
2. The single-valued record-backed arm emits your snippet verbatim: Record parentRecord = ((Payload) env.getSource()).<accessor>(). So it is affected identically, as you expected.
3. Your byte-identity observation is exact. Diffing the generated class with and without the errors field, the only difference is the added errors method; the polymorphic fetcher body is unchanged.

Root cause. The generator computes a per-type sourceIsOutcome flag from the payload's own WrapperArm errors field and threads it into the monomorphic emit paths. None of the multi-table polymorphic call sites in the same dispatch receive it, so that emitter has no way to know the parent is wrapped, and two sites then bind the parent off env.getSource() directly. The helper the fix needs already exists and is simply unused on this path: the parent-key extraction has a source-bound overload added precisely so an arm-switching caller can repoint a field's own read at success.value().

Worth naming separately, because it is the reason this compiles clean rather than failing the build: we have an arm-switch validator meant to be exactly this backstop, but it only covers fields that would fall through to graphql-java's default PropertyDataFetcher. A polymorphic child field registers a real emitted fetcher, so it passes the guard while still reading off the wrong object. Whether that invariant can be widened so the next emit path added under a wrapper payload cannot repeat this silently is on the item as an open question for its spec, alongside the fix itself.

Affected shapes, from the reproduction and from reading the emitter: batched list and connection on both table-backed and record-backed parents, plus the single-valued inline form on both. No need to move this to a fresh issue; R873 tracks it.

On case 2: noted, and thanks for reporting back even though there was nothing to file. Reports that something worked are genuinely useful to us, and the self-referencing-participant and null-hub-row details you verified are more than we had pinned. Nothing further needed there.

One caveat on your workaround, since you mentioned the contract is about to be frozen. The redundant single-column FK you added to sidestep the [deferred] batched parent-holds-FK rejection is a real schema change on your side, not just a generator-facing hint. When that gap closes it becomes redundant rather than wrong, so it does not trap you, but it is worth recording as deliberate so it is not later read as an accident.

---

Generated by Claude Code