`@orderBy`/`@defaultOrder` silently ignored on multitable interface queries

[krhoybraten-sikt]

Summary

On a Query field returning a multitable interface (implementations spread across
tables), both @defaultOrder on the field and a user-supplied @orderBy input
compile without errors but have no effect at runtime — results always come back
in primary-key order.

type Query {
  applikasjoner(
    filter: ApplikasjonerFilterInput
    orderBy: ApplikasjonerOrderByInput @orderBy
  ): [Applikasjon] @asConnection(defaultFirstValue: 100) @defaultOrder(fields: [{name: "NAVN"}])
}

input ApplikasjonerOrderByInput {
  direction: OrderDirection!
  orderByField: ApplikasjonerOrderByField!
}

enum ApplikasjonerOrderByField {
  NAVN @order(fields: [{name: "NAVN"}])
}

Applikasjon is a multitable interface with three implementing @table types
(feide_applikasjon, maskinporten_applikasjon, maskinbruker_applikasjon);
all three tables have the NAVN column.

Version: 10.0.0-RC30

Expected behaviour

Either results ordered by NAVN (default @defaultOrder, overridable by the
orderBy input) — or, if multitable ordering is unsupported, an author-error at
generate time like the one @condition-overloads produce, so the schema author
finds out at build time rather than the client at runtime.

Actual behaviour

Codegen succeeds. At runtime orderBy: {direction: ASC, orderByField: NAVN} and
orderBy: {direction: DESC, orderByField: NAVN} return identical results in
primary-key order:

ASC:  fs.sikt.no (test), FS Admin (test), Min kompetanse (test), rasbruker_7778
DESC: fs.sikt.no (test), FS Admin (test), Min kompetanse (test), rasbruker_7778
      (subjekt_id -23, -22, -21, -16 — i.e. PK ascending)

(Observed via Apollo Router against the subgraph; same behaviour without the
router. Filters via @condition on the same query work correctly, so the input
reaches the generated query — only the ordering is dropped.)

Notes

• Documentation ("Sorting", "Polymorphic queries") does not state a multitable
  limitation for @orderBy/@defaultOrder; the @condition section explicitly
  covers multitable, which suggests ordering was simply not wired up for the
  multitable code path.
• Workaround used meanwhile: client-side sorting of each fetched page (imperfect
  across pagination) in fs-admin.

[krhoybraten-sikt]

Additional case, same silent-drop behaviour but on a nested reference list rather than the root query field:

@defaultOrder on a @splitQuery @reference list field is silently ignored when the parent query is a multitable interface query.

interface Applikasjon { ... }   # three @table implementations

type MaskinbrukerApplikasjon implements Applikasjon @table(name: "maskinbruker_applikasjon") {
  tilganger: [ApplikasjonTilgang]
      @splitQuery
      @reference(path: [{key: "maskinbruker_applikasjon__fk_maskinbruker_applikasjon_subjekt"},
                        {key: "subjektrolletildeling_med_arv__fk_srt_med_arv_subjekt"}])
      @defaultOrder(fields: [{name: "ROLLEKODE"}])
}

Observed on 10.0.0-RC30 with ApplikasjonTilgang backed by a view (no PK; the second reference key is a synthetic FK): querying the interface field (applikasjoner, @asConnection multitable) returns the nested tilganger rows in raw view order — LES_MEG, ADMIN_MEG, SKRIV_MEG where ROLLEKODE ordering would give ADMIN_MEG, LES_MEG, SKRIV_MEG. No warning.

The twist that makes this worse than the root-field case: schema validation itself demands the directive. Without @defaultOrder the build fails with

Author error: Field 'Query.x': list fields must have a deterministic order.
Add a primary key to the target table, or use @defaultOrder or @orderBy.

— so for view-backed types (which have no PK) the author is forced to add @defaultOrder, and codegen then ignores it. The validator and the generator disagree about whether the order exists.

For contrast: the same target type ordered via an orderBy argument on a single-table parent path works correctly (verified live on the same schema), consistent with the original report — the loss seems specific to multitable parents.

[alf]

Thanks for filing this, and for the ASC/DESC comparison plus the note that @condition filters work on the same query. That isolated it precisely.

Three plan pages cover it, one per half plus the class behind both:

• Lower orderBy onto multitable-interface/union queries owns the root field you led with. It predates your report, and your report corrected the mechanism we had written down. QueryInterfaceField and QueryUnionField carry no ordering slot at all, so @defaultOrder is discarded along with the orderBy argument. That is also why nothing rejects the field: both build-time ordering checks are gated on an interface these two arms do not implement, so a paginated multitable root with no ordering passes the check written to reject exactly that shape.
• @defaultOrder on a @splitQuery child list is dropped at emit owns the nested child list from your follow-up comment. One correction there: we think the axis is @splitQuery versus inline rather than the parent being multitable, because two plain object-type fixtures in our example schema lose ordering the same way. Worth flagging, since it means these are two separate fixes rather than one.
• The never-unsorted-list invariant owns the class behind both: an ordering the model resolved that never reaches the emitted SQL, with no check comparing the two ends. Your coordinate is one of four known leak sites.

On your alternative ask: a generate-time author error, if multitable ordering stays unsupported, is on the table as a first increment. It is far cheaper than the lowering work and it turns a silent wrong answer into a build failure. It would break schemas that compile today, but the ones it breaks are the ones already getting wrong results.

Please push back on any of this here, particularly the @splitQuery attribution.

---

Generated by Claude Code

[krhoybraten-sikt]

Related finding, filed as #538: the same silent-drop behaviour on a different coordinate — @defaultOrder on a nested @reference list field without @asConnection generates no ORDER BY and no author-error (RC35, verified byte-identical generated code with and without the directive). Between this issue's multitable-root case and #538's nested-list case, the pattern is that unsupported ordering coordinates drop silently rather than failing the build — worth treating the author-error as the general fix across coordinates, not per-site.