What does a GraphQL server do for a schema field that has no resolver of its own?

## What execution needs, field by field GraphQL execution walks the selection set of an operation and, for **every field selected in the document**, has to produce a value. There is no "skip" branch: if the client asked for `designator`, a value for `designator` must appear under that response key. So execution needs, per field, some function it can call to obtain a raw value before that value is checked against the field's declared type. Hand-writing that function for every field in a large schema would be absurd. In an airline seat-map graph, a `Seat` type might declare `designator`, `cabin`, `row`, `column`, `hasPower`, `isExitRow` — and all six of those are already sitting on the seat record the parent field loaded. Writing six functions that each say "return the member of the same name" is pure ceremony. ## The fallback rule So every mainstream server ships a **default field resolver**: when the type system has no resolver registered for a field, execution uses a generic one that looks up a member of the same name on the **parent value** — the value the field one level up already resolved — and returns it unchanged. "Member of the same name" is deliberately loose, because the parent value is whatever the host language happens to hold: an object with a property, a record with a getter, a dictionary or map with a key, a row-like structure. The default resolver's job is to bridge the schema's field name to that member. Many implementations add one more step: if the member it finds is itself callable, the default invokes it rather than returning the function value. That is a convention, and it varies, so it is not something to design a schema around. ``` function defaultResolve(parentValue, fieldName, args): if parentValue is null: return null member = lookupMember(parentValue, fieldName) # property, getter, or map key if member is absent: return NOTHING # completed as null if member is callable: return call(member) # common, not universal return member ``` Two things this rule does **not** do are worth stating plainly. It performs no I/O — it never queries a database, calls a service, or reads a cache; it only reads memory it was handed. And it makes no use of the field's arguments, so a field that means anything by its arguments needs code of its own. ## Which fields still need a resolver Four families fall outside the rule: * **Computed or derived fields.** `Seat.isBlockedForCrew` is not stored on a seat record; it is a decision made from the aircraft's crew-rest configuration and today's roster. No member of that name exists to read, so without a resolver the field yields null. * **Fields whose backing member is named differently.** The schema says `designator`; the loaded record calls it `seatLabel`. The default looks for `designator`, finds nothing, and produces null. * **Fields that take arguments.** Arguments are validated and coerced by execution and then passed to the resolver, and the default ignores them entirely. * **Fields whose data lives somewhere else.** `Seat.currentHold` may require a lookup against a hold store. Nothing on the parent value can answer it. ## What happens when there is nothing to read This is the part that surprises people, because it is quiet. Default resolution finding no member is not an error — it simply produced no value, which is completed as `null`. If the field is nullable, the client gets `"designator": null` with **no entry in the response's errors list at all**. The typo, the renamed column, the field someone added to the SDL and forgot to wire — all of them look like legitimately absent data. Only a Non-Null declaration turns the silence into a field error. ```graphql type Seat { designator: String! # read straight off the loaded seat record cabin: Cabin! # same isBlockedForCrew: Boolean! # computed - needs its own resolver } ``` ## It is a convention, not a specified rule The specification does not describe property lookup. It treats each field's resolver as an internal function the type system provides and says nothing about how that function computes a value; default resolution is the near-universal answer implementations chose independently. The practical consequence is that the rule is *similar* everywhere and *identical* nowhere: name matching, getter recognition, map handling and callable invocation all differ in detail. SDL that resolved perfectly under one server can come up full of nulls under another with no schema change at all, because the schema never carried the binding rule. ## How to talk about it The useful framing in an interview is that default resolution defines the **boundary of hand-written code** in a GraphQL server. The fields you write resolvers for are exactly the fields that are computed, renamed, argument-driven, or backed by a different source. Everything else is the parent value already in hand, read by name.