Hacker DirectoryHacker Directory
Continue learning
TRSave HTML ↓

WEB / WEB-17.03

GraphQL execution model

Which response portion does a field failure erase, and where do validation and permission differ?

CORE · RED · BLUE · ARTIFACT · PRACTICE

1. Core · Mechanism

Read every scenario without motion

Full result

  1. Read prepared

    The client prepared BookTitle for book-A with selection id/title/subtitle. The schema belongs to the server; the query/ID grants no resource permission and the executor has not received the operation.

    GraphQL reader
    book-A; id/title/subtitle ready
    Atlas executor
    Schema ready; no request
  2. Request arrived

    The operation and variables reached the server; parsing, validation and resolver execution remain pending.

    GraphQL reader
    Book operation ready
    Atlas executor
    Operation arrived; parse pending
  3. Local parse

    This fixture declares successful parsing; it uses a selected operation ledger rather than a real language parser.

    GraphQL reader
    Book operation ready
    Atlas executor
    Parsed declared; validation pending
  4. Validate/coerce

    Known fields and declared ID input pass; object policy remains a separate decision in resolver context.

    GraphQL reader
    Book operation ready
    Atlas executor
    Validated/coerced; resolve pending
  5. Local resolver

    Declared policy permits the read; local book/field outcomes await completion before the error boundary is selected.

    GraphQL reader
    Book operation ready
    Atlas executor
    Resolved fixture; completion pending
  6. Typed completion

    Field completion prepares the selected id/title/subtitle values as a complete data.book result.

    GraphQL reader
    Book operation ready
    Atlas executor
    data.book complete; result ready
  7. Result arrived

    The client received the result body; this scene does not produce an HTTP status or evidence of an actual GraphQL engine.

    GraphQL reader
    Result received; UI mapping pending
    Atlas executor
    data.book complete; result ready
  8. Local UI decision

    The reader admits this result’s id/title/subtitle as new book UI data. This local mapping decision is not browser DOM or pixel measurement and occurs only after result arrival.

    GraphQL reader
    title/subtitle displayed
    Atlas executor
    data.book complete; result ready

Validation denied

  1. Read prepared

    The client prepared BookTitle for book-A with selection id/title/caption. The schema belongs to the server; the query/ID grants no resource permission and the executor has not received the operation.

    GraphQL reader
    book-A; id/title/caption ready
    Atlas executor
    Schema ready; no request
  2. Request arrived

    The operation and variables reached the server; parsing, validation and resolver execution remain pending.

    GraphQL reader
    Book operation ready
    Atlas executor
    Operation arrived; parse pending
  3. Local parse

    This fixture declares successful parsing; it uses a selected operation ledger rather than a real language parser.

    GraphQL reader
    Book operation ready
    Atlas executor
    Parsed declared; validation pending
  4. Validation boundary

    The selected caption field is absent from the schema; execution never starts and an error result without data is prepared.

    GraphQL reader
    Book operation ready
    Atlas executor
    Validation denied; calls=0; errors ready
  5. Request error arrived

    The client received a pre-execution error result; absent data is different from data:null.

    GraphQL reader
    errors received; data absent
    Atlas executor
    Validation denied; calls=0; errors ready

Nullable error

  1. Read prepared

    The client prepared BookTitle for book-A with selection id/title/subtitle. The schema belongs to the server; the query/ID grants no resource permission and the executor has not received the operation.

    GraphQL reader
    book-A; id/title/subtitle ready
    Atlas executor
    Schema ready; no request
  2. Request arrived

    The operation and variables reached the server; parsing, validation and resolver execution remain pending.

    GraphQL reader
    Book operation ready
    Atlas executor
    Operation arrived; parse pending
  3. Local parse

    This fixture declares successful parsing; it uses a selected operation ledger rather than a real language parser.

    GraphQL reader
    Book operation ready
    Atlas executor
    Parsed declared; validation pending
  4. Validate/coerce

    Known fields and declared ID input pass; object policy remains a separate decision in resolver context.

    GraphQL reader
    Book operation ready
    Atlas executor
    Validated/coerced; resolve pending
  5. Local resolver

    Declared policy permits the read; local book/field outcomes await completion before the error boundary is selected.

    GraphQL reader
    Book operation ready
    Atlas executor
    Resolved fixture; completion pending
  6. Typed completion

    The nullable subtitle error stops at subtitle:null. id/title remain available and errors are included in the same result.

    GraphQL reader
    Book operation ready
    Atlas executor
    subtitle:null + errors; result ready
  7. Result arrived

    The client received the result body; this scene does not produce an HTTP status or evidence of an actual GraphQL engine.

    GraphQL reader
    Result received; UI mapping pending
    Atlas executor
    subtitle:null + errors; result ready
  8. Local UI decision

    The reader retains usable title=Atlas Notları while selecting an error state for subtitle:null using path book/subtitle. Data and errors are read together; this step measures no actual DOM rendering.

    GraphQL reader
    title visible; subtitle error state
    Atlas executor
    subtitle:null + errors; result ready

Non-null spread

  1. Read prepared

    The client prepared BookTitle for book-A with selection id/title/subtitle. The schema belongs to the server; the query/ID grants no resource permission and the executor has not received the operation.

    GraphQL reader
    book-A; id/title/subtitle ready
    Atlas executor
    Schema ready; no request
  2. Request arrived

    The operation and variables reached the server; parsing, validation and resolver execution remain pending.

    GraphQL reader
    Book operation ready
    Atlas executor
    Operation arrived; parse pending
  3. Local parse

    This fixture declares successful parsing; it uses a selected operation ledger rather than a real language parser.

    GraphQL reader
    Book operation ready
    Atlas executor
    Parsed declared; validation pending
  4. Validate/coerce

    Known fields and declared ID input pass; object policy remains a separate decision in resolver context.

    GraphQL reader
    Book operation ready
    Atlas executor
    Validated/coerced; resolve pending
  5. Local resolver

    Declared policy permits the read; local book/field outcomes await completion before the error boundary is selected.

    GraphQL reader
    Book operation ready
    Atlas executor
    Resolved fixture; completion pending
  6. Typed completion

    The non-null title error propagates to the nearest nullable ancestor Query.book. data.book:null and errors are prepared.

    GraphQL reader
    Book operation ready
    Atlas executor
    data.book:null + errors; result ready
  7. Result arrived

    The client received the result body; this scene does not produce an HTTP status or evidence of an actual GraphQL engine.

    GraphQL reader
    Result received; UI mapping pending
    Atlas executor
    data.book:null + errors; result ready
  8. Local UI decision

    The reader selects a new unavailable Book state because data.book:null. Error path is book/title; a stale title is not reused as new success. The data object exists with a null book; data is not absent.

    GraphQL reader
    No book; stale title not reused
    Atlas executor
    data.book:null + errors; result ready

ACTORS · STATE · DATA FLOW

A selection set is not a business workflow

GraphQL lets a client select response fields from a typed schema. Atlas uses Query.book(id: ID!): Book and selects id/title/subtitle. The schema is an API field/type contract, not necessarily a one-to-one database schema. A query produces a read result, a mutation describes a top-level change operation, and a subscription produces a response stream tied to source events. This lesson follows an ordinary read query only; subscription transport and mutation transactions are outside the animation.

The document is parsed according to the language grammar, then validated for known fields, selections appropriate to their types and valid variable usage. The id variable is coerced to the selected operation’s ID! input. An unknown caption selection is a request error at this boundary; executing a book resolver and hiding the invalid field afterward is different behavior. An unchanged operation validated earlier can be memoized; validation need not be a freshly repeated network step on every request.

From resolver result to typed response

A resolver produces a field value using its parent value, field arguments and server-created context. Atlas uses declared session/tenant permission and reads book-A from a fixed local record. A resolver call is not automatically an HTTP request; this in-memory lookup is a local step in the scene. Field completion follows the schema type, executing selected child fields or coercing a scalar result. Copying every runtime object member into the response is not equivalent to executing a selection set.

If nullable subtitle:String raises a resolver error, subtitle:null can coexist with an errors list while id/title complete successfully. A title:String! failure cannot leave a null title inside Book: it propagates to the nearest nullable ancestor, Query.book, producing data.book:null. Making Book non-null would propagate further; an all-non-null chain can produce data:null. The error path still identifies the original failing response position even when null propagates, using response names when aliases are involved.

Execution results and HTTP results differ

A request that never starts execution because of parsing, validation or input coercion errors returns errors without a data member. Field failures after execution starts can produce data together with errors; data:null is different from an absent data member. Browser network success or an HTTP status alone does not prove that every selected field succeeded. A UI can inspect the book value and error paths together, show title, and choose a local subtitle error state without exposing raw internal exception text.

The released September 2025 GraphQL execution specification prescribes no particular HTTP status; transport is a separate profile. The reviewed current GraphQL-over-HTTP draft addresses body/media types and status separately. Its §5.4 recommends custom 294 for partial data plus errors, while the §5.4.1 execution-error example says 200. This internally inconsistent draft is not the contract of every deployment. The artifact models result bodies and execution ledgers without inventing HTTP statuses. Real clients must verify pinned server/adapter profiles, media types and gateway responses; neither GraphQL always returns 200 nor all partial results use 294 is a reliable generalization.

2. Red · Trust & Impact

Read every scenario without motion

Validation deny

  1. Selection and context were separated

    The BookTitle query selects id, title and subtitle for book. Knowing schema fields does not mean object permission has been established for reader-A.

    Operation and schema
    Query selection
    Validation/completion decision
    Permission separate
    Consumer interpretation
    Execution pending
  2. The negative-selection record was selected

    The validation-denied row selects caption instead of subtitle. Although parseDeclared and variablesDeclaredValid are true, caption is not a Book field in the schema.

    Operation and schema
    Selected: caption
    Validation/completion decision
    Parse declared=true
    Consumer interpretation
    Validation pending
  3. Validation stopped before execution

    This row declares resolverCalls=0 and an Unknown selected field error. Valid syntax does not automatically advance into execution.

    Operation and schema
    Resolver calls=0
    Validation/completion decision
    Request error known
    Consumer interpretation
    No execution data
  4. The request-error shape was preserved

    The result contains only errors and omits data. This shape is not the same as a field returning null during execution.

    Operation and schema
    errors present
    Validation/completion decision
    data absent
    Consumer interpretation
    Execution did not begin
  5. No leap was made to a permission outcome

    The caption mismatch answers a schema question. It establishes neither unauthenticated status, access to another book nor successful service policy.

    Operation and schema
    Validation deny known
    Validation/completion decision
    Permission unestablished
    Consumer interpretation
    No resource body
  6. Model and engine scope were separated

    This ledger declares parsing and field outcomes with actualParser=false and actualEngine=false. The resolver count belongs to the supplied profile, not a production-engine trace.

    Operation and schema
    Declared pipeline
    Validation/completion decision
    No engine execution claim
    Consumer interpretation
    No resource delivery

Non-null effect

  1. The field-nullability chain was read

    In the selected schema title is String! while book is nullable. A title completion error can propagate to the nearest nullable parent, book.

    Operation and schema
    title: non-null
    Validation/completion decision
    book: nullable
    Consumer interpretation
    Completion pending
  2. The title-failure row was selected

    The nonnull-error row declares resolverFault=title and resolverCalls=4. This profile has all field results ready before completion without claiming general executor ordering.

    Operation and schema
    Fault: title
    Validation/completion decision
    Declared calls=4
    Consumer interpretation
    Result not completed
  3. The error propagated to its parent

    The result has data.book=null while the error path remains book/title. Showing an old title or successful subtitle as a new complete Book would violate the contract.

    Operation and schema
    data.book=null
    Validation/completion decision
    Path: book/title
    Consumer interpretation
    Book view unavailable
  4. A different schema was not assumed

    The artifact’s rootBookNonNullVariant describes another unselected schema. Here book is nullable, so the data object remains; the result is not expanded to data=null.

    Operation and schema
    Selected book nullable
    Validation/completion decision
    data object retained
    Consumer interpretation
    No schema substitution
  5. The nullable-subtitle contrast was established

    A subtitle error can retain title with subtitle=null. Losing book on a non-null title error comes from nullability, not network speed.

    Operation and schema
    Subtitle: partial Book
    Validation/completion decision
    Title: Book=null
    Consumer interpretation
    Blast radius schema-bound
  6. No transport outcome was invented

    GraphQL result shape alone does not select an HTTP status. With transportStatusMode=not-modeled, no automatic 200 or 500 is added to this completion result.

    Operation and schema
    Execution error known
    Validation/completion decision
    HTTP status not modeled
    Consumer interpretation
    No stale Book delivery

ASSUMPTION · BOUNDARY · CONTROL

Does a visible schema grant resource access?

The presence of a book field means that the field exists in the API contract. Accepting an ID variable, authenticating a connection or validating a selection does not authorize the subject to read that resource. Enforce object/action decisions from trusted server context in the resolver or its service boundary. A risky assumption is that one general allow at the root automatically covers every nested field. Adding a sensitive author/profile field may require its own field/resource policy; the public schema is not a permission list.

The resolver context begins with permissionAllowed=true; authentication and database tenant isolation are not verified here. A successful query does not imply that every sibling field carries the same permission. Equating parsing with permission, treating client variables as trusted context, or sharing a cache without subject/tenant binding are separate control problems. Response shape alone does not establish their cause; context provenance and the enforcement point for each resource decision also matter.

Mistaking a partial result for complete success

A subtitle error can accompany a successful title. Turning every errors member into a global failure discards useful data unnecessarily; ignoring errors merely because data exists can display incorrect subtitle information. Non-null decisions have a failure radius: making optional information non-null can erase the whole Book view after a small resolver failure. The artifact compares two field-error results for the same normal record; the difference is the schema’s nullability chain rather than network speed.

One telemetry label for request and execution errors hides their different causes. An unknown caption selection should have zero resolver calls; a nullable subtitle error occurs after execution begins. Serial execution of mutation root fields also does not guarantee transactional nested work or ordering of every field. Timeout, cancellation, resource cost and downstream failure policy remain application design decisions. Permission and ordinary capacity limits belong together; a type-safe selection is not permission for unlimited work.

3. Blue · Secure development & defense

Read every scenario without motion

Partial data

  1. The nullable-field observation was selected

    The nullable-error row has resolverFault=subtitle and resolverCalls=4. It is not validation denial; the execution result contains both data and errors.

    Result/context observation
    Fault: subtitle
    Pipeline comparison
    Calls=4
    Review conclusion
    Completion review pending
  2. Available data fields were read

    book.id=book-A and title=Atlas Notları remain with subtitle=null. Data presence does not mean no error; an error does not mean all data is unusable.

    Result/context observation
    id/title present
    Pipeline comparison
    subtitle=null
    Review conclusion
    Partial result known
  3. The error path was bound to the data field

    The error path is book/subtitle. The human-readable Subtitle unavailable message is not used as a stable field identifier; the path describes the response field position.

    Result/context observation
    Path: book/subtitle
    Pipeline comparison
    Error/data linkage
    Review conclusion
    Message ≠ stable ID
  4. The client-interpretation boundary was recorded

    Title may remain usable, but the subtitle error must remain explicit. This documentary review proves neither actual DOM rendering nor correct client state.

    Result/context observation
    Title available in result
    Pipeline comparison
    Subtitle error retained
    Review conclusion
    DOM outcome unobserved
  5. Call count was bound to the profile

    Four calls belong to this ledger’s selected completion profile. A real executor may cancel pending siblings; the same count is not expected of every engine.

    Result/context observation
    Declared calls=4
    Pipeline comparison
    Cancellation not modeled
    Review conclusion
    No universal count claim
  6. The review tuple was completed

    Validation outcome, resolver invocation, data shape and error path are retained together. HTTP adapter status and permission enforcement need separate evidence.

    Result/context observation
    Partial completion known
    Pipeline comparison
    Adapter evidence separate
    Review conclusion
    Permission evidence separate

Resolver context

  1. The context-provenance record was opened

    Context contains reader-A, tenant-A and permissionAllowed=true with provenanceDeclared=owned handler. These are ledger preconditions, not observations of actual login or token validation.

    Result/context observation
    reader-A / tenant-A
    Pipeline comparison
    Permission declared=true
    Review conclusion
    Provenance review pending
  2. Variables and trusted context were separated

    variables.id=book-A selects the requested resource. Matching the variable schema does not turn it into an authenticated subject or server tenant authority.

    Result/context observation
    Variable selects book-A
    Pipeline comparison
    Context selects subject/tenant
    Review conclusion
    Authority roles separate
  3. The normal result was compared with context

    The normal row returns id, title and subtitle. This positive shape shows the declared result under the supplied context without observing every nested resource policy.

    Result/context observation
    Normal result complete
    Pipeline comparison
    Context precondition declared
    Review conclusion
    Nested policies unobserved
  4. Cache scope remained a review question

    Subject/tenant binding must be preserved in loaders and caches. The artifact shows no cache implementation, so a normal Book result cannot prove those bindings were enforced.

    Result/context observation
    Cache binding required
    Pipeline comparison
    Cache evidence missing
    Review conclusion
    No clean cache conclusion
  5. A connection was not converted into authority

    connectionGrantsObjectPermission=false is a separate boundary. Establishing HTTP or another connection cannot replace book-read permission; schema visibility is not a permission list.

    Result/context observation
    Connection ≠ object permission
    Pipeline comparison
    Schema ≠ grant list
    Review conclusion
    Per-resource decision needed
  6. The conclusion retained its evidence level

    Review shows that the normal result depends on the supplied context. Authentication, tenant storage isolation and actual engine behavior remain outside these records.

    Result/context observation
    Declared context/result linked
    Pipeline comparison
    Runtime identity unobserved
    Review conclusion
    No broader acceptance claim

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Observe pipeline decisions separately

Pin the schema edition and operation contract, then observe parsing, validation, variable coercion, resolver invocation and completion separately. An operation alias, correlation ID and bounded error path can provide evidence without logging sensitive values or every query text. The unknown-field branch proves no execution through resolver count=0. In the normal branch, invocation evidence matches the response selection. These counts belong to the local fixture ledger, not a production engine, distributed trace or query-planner benchmark. The artifact count belongs to a profile with all selected field outcomes prepared before completion; a real executor may cancel pending sibling work.

The request handler creates trusted context; a user-provided tenant value is not copied into it as a trusted identity. The object-read decision controls which records a local service may return while error shapes remain contractual and avoid sensitive internal details. Request-scoped caches and loaders preserve permission bindings. An in-memory resolver still needs policy; a network resolver does not supply policy automatically. Review first asks where the resource decision occurs, before counting calls.

Tie client rendering to nullability

Keep four ordinary outcomes for the same book: a full result, validation denial before execution, nullable subtitle failure and non-null title propagation. The client distinguishes absent data from data:null and must not present a stale title as the new book result after propagation. In the partial subtitle branch, title remains usable while the subtitle error state stays visible. Test alias-aware UI mapping when error paths change; human-readable messages are not stable identifiers.

Verify the HTTP adapter’s media types and error-status policy separately; a core execution result does not determine gateway behavior by itself. GraphQL-over-HTTP draft recommendations need to be evaluated against implementation support. The scene shows client/server request and result arrivals, while parse, validate, resolve and complete are local server stages. The artifact explains a typed-result ledger; actual engine scheduling, HTTP adapters and storage integration cannot be reduced to that table.

NOW APPLY IT TO THE CASE

Which separate evidence is needed for validation, execution and permission?

The typed ledger separates unknown caption, nullable subtitle and non-null title outcomes. Resolver context is a precondition; data shape proves neither actual authentication nor HTTP status.

Examine the case API contract separately from the representation readable by the browser. Discuss sufficient evidence for envelope, data, errors and resource permission.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Atlas typed execution ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations
{
  "profile": {
    "releasedEdition": "September 2025",
    "operationKind": "query",
    "transportStatusMode": "not-modeled",
    "actualParser": false,
    "actualEngine": false,
    "permissionDeclared": true,
    "localPersistence": true,
    "allFieldResultsDeclaredBeforeCompletion": true,
    "cancellationNotModeled": true,
    "executorMayCancelPendingSiblings": true
  },
  "schemaSDL": "type Query { book(id: ID!): Book }\ntype Book { id: ID! title: String! subtitle: String }",
  "operation": "query BookTitle($id: ID!) { book(id: $id) { id title subtitle } }",
  "variables": {
    "id": "book-A"
  },
  "types": {
    "book": {
      "nullable": true
    },
    "id": {
      "nullable": false
    },
    "title": {
      "nullable": false
    },
    "subtitle": {
      "nullable": true
    }
  },
  "context": {
    "subject": "reader-A",
    "tenant": "tenant-A",
    "permissionAllowed": true,
    "provenanceDeclared": "owned handler"
  },
  "record": {
    "id": "book-A",
    "title": "Atlas Notları",
    "subtitle": "Web rehberi"
  },
  "rows": [
    {
      "case": "normal",
      "selectedFields": [
        "id",
        "title",
        "subtitle"
      ],
      "parseDeclared": true,
      "variablesDeclaredValid": true,
      "resolverFault": null,
      "resolverCalls": 4,
      "result": {
        "data": {
          "book": {
            "id": "book-A",
            "title": "Atlas Notları",
            "subtitle": "Web rehberi"
          }
        }
      }
    },
    {
      "case": "validation-denied",
      "selectedFields": [
        "id",
        "title",
        "caption"
      ],
      "parseDeclared": true,
      "variablesDeclaredValid": true,
      "resolverFault": null,
      "resolverCalls": 0,
      "result": {
        "errors": [
          {
            "message": "Unknown selected field"
          }
        ]
      }
    },
    {
      "case": "nullable-error",
      "selectedFields": [
        "id",
        "title",
        "subtitle"
      ],
      "parseDeclared": true,
      "variablesDeclaredValid": true,
      "resolverFault": "subtitle",
      "resolverCalls": 4,
      "result": {
        "data": {
          "book": {
            "id": "book-A",
            "title": "Atlas Notları",
            "subtitle": null
          }
        },
        "errors": [
          {
            "message": "Subtitle unavailable",
            "path": [
              "book",
              "subtitle"
            ]
          }
        ]
      }
    },
    {
      "case": "nonnull-error",
      "selectedFields": [
        "id",
        "title",
        "subtitle"
      ],
      "parseDeclared": true,
      "variablesDeclaredValid": true,
      "resolverFault": "title",
      "resolverCalls": 4,
      "result": {
        "data": {
          "book": null
        },
        "errors": [
          {
            "message": "Title unavailable",
            "path": [
              "book",
              "title"
            ]
          }
        ]
      }
    }
  ],
  "pipeline": [
    "parse",
    "validate",
    "coerce variables",
    "resolve with trusted context",
    "complete typed fields",
    "build execution result"
  ],
  "allNonNullQualification": {
    "rootBookNonNullVariant": true,
    "rootDataOnTitleError": null,
    "notSelectedSchema": true
  },
  "httpScope": {
    "corePrescribesStatus": false,
    "draftURL": "https://http-spec.graphql.org/draft/",
    "draftReviewed": "2026-10-08",
    "draftPartialRecommendation": 294,
    "finalStandard": false,
    "actualHTTP": false,
    "draftExampleExecutionErrorStatus": 200,
    "draftRecommendationsConflict": true
  },
  "boundaries": {
    "schemaGrantsPermission": false,
    "connectionGrantsObjectPermission": false,
    "errorPathUsesResponseNames": true,
    "requestErrorOmitsData": true
  }
}
schemaSDL
Selected query schema and nullable Book/subtitle chain.
rows
Four outcomes for the same record; no claim of an executed GraphQL engine.
types
Which nullable ancestor stops field-error propagation.
context
Declared permission; client variables differ from trusted context.
httpScope
Boundary between released core and changing HTTP draft/profile.

Original inert SDL, ordinary read document and typed result ledger; no actual GraphQL parser, validator, engine, endpoint, HTTP status or database execution.

Two reality checks

Schema validation is authorization.

Validation checks the operation’s type contract; object/action permission is enforced separately from trusted context.

There can be no data when errors exist.

An execution error can coexist with partial data; a pre-execution request error omits data.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

Selected fields are id, title, caption, but caption is absent from the schema. Does resolver execution occur?

  1. No; resolverCalls=0 and request errors without data.
  2. Yes; an unknown field is handled by having a resolver return null.
Read the explained answer

No; resolverCalls=0 and request errors without data. — The validation-denied branch does not reach execution; parsing operation syntax does not establish field validity.

Why does a title non-null error produce data.book=null?

Selected lesson artifact fields; teaching example

types.title
{"nullable":false}
types.book
{"nullable":true}
rows[3].result
{"data":{"book":null},"errors":[{"message":"Title unavailable","path":["book","title"]}]}
  1. A non-null error only omits title; book always remains complete.
  2. title cannot be null; failure propagates to nullable book.
Read the explained answer

title cannot be null; failure propagates to nullable book. — The selected schema makes book nullable. Result errors carry path book/title while parent data becomes null.

A nullable-subtitle fault returns data+errors. Why does errors presence establish neither a data-free operation nor an exact HTTP status?

Read the explained answer

A validated query may execute; a nullable-field fault produces subtitle=null and errors alongside usable id/title. Request-validation errors omit data. GraphQL core alone does not determine HTTP-status mapping; this artifact executes no actual engine/HTTP exchange and declares sibling results without timing guarantees.

□ I distinguished request from execution errors.

□ I inferred no exact HTTP status from the data/errors shape.

Open the application console · request / response / browser
Also open request, URL, cookie and DOM examples

Sources and scope

  • GraphQL Specification — September 2025 released edition§2.1 language parsing; §6.1.1 validation; §6.1.2 variable coercion · §6.4.2 resolving fields; §6.4.3 completion; §6.4.4 errors · §7.1.1 execution result; §7.1.3 request error result; §7.1.4 response position · §6.3.3 Non-Null sibling cancellation; §6.3.4 normal and serial execution
  • GraphQL over HTTP — current draft§5.1 body/media type; §5.4 status codes · §6.1 Partial success; custom 294 draft qualification · §5.4 custom 294 recommendation versus §5.4.1 execution-error 200 example: reviewed inconsistency