Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support partial responses #114

Open
stuebingerb opened this issue Nov 28, 2024 · 0 comments
Open

Support partial responses #114

stuebingerb opened this issue Nov 28, 2024 · 0 comments
Labels
bug Something isn't working enhancement New feature or request

Comments

@stuebingerb
Copy link
Owner

According to the spec, there is a distinction between "request errors" and "field errors" (and it would most likely make sense to have that distinction in our code base as well).

Field errors are raised during execution from a particular field. This may occur due to an internal error during value resolution or failure to coerce the resulting value.

Field errors must result in a partial response, i.e. a response with data entry and all (unique) raised field errors in the errors entry. If a field error occurs on a nullable field, the value of that field will be coerced to null. Otherwise, the error propagates to the parent field where it will be handled similarly (if the parent is nullable, it will be coerced to null, otherwise the error propagates further).

Consider the following schema:

{
    type<Test> {
        property<String>("optional") {
            resolver { test: Test ->
                if (test.fail) {
                    null as String
                } else {
                    "success"
                }
            }
        }
    }
    query("test") {
        resolver { fail: Boolean ->
            Test(fail)
        }
    }
}

Happy case:

query {
  test(fail:false) {
    optional
    fail
  }
}

Result:

{
  "data": {
    "test": {
      "optional": "success",
      "fail": false
    }
  }
}

Error case:

query {
  test(fail:true) {
    optional
    fail
  }
}

Result:

{
  "errors": [
    {
      "message": "null cannot be cast to non-null type kotlin.String",
      "locations": [
        {
          "line": 3,
          "column": 5
        }
      ],
      "path": [],
      "extensions": {
        "type": "INTERNAL_SERVER_ERROR"
      }
    }
  ]
}

Expected would IMHO be a partial response along the lines of:

{
  "data": {
    "test": {
      "optional": null,
      "fail": true
    }
  },
  "errors": [
    {
      "message": "null cannot be cast to non-null type kotlin.String",
      "locations": [
        {
          "line": 3,
          "column": 5
        }
      ],
      "path": [],
      "extensions": {
        "type": "INTERNAL_SERVER_ERROR"
      }
    }
  ]
}

IMHO incorrect error handling should be considered a bug but there is definitely potential for related enhancement as well.

See

@stuebingerb stuebingerb added bug Something isn't working enhancement New feature or request labels Nov 28, 2024
stuebingerb added a commit that referenced this issue Feb 3, 2025
This adds first support for schema stitching without aiming for full
feature compatibility. And while I have a pretty extensive internal
use case, schema stitching is still to be considered experimental and
subject to change as needed.

Schema stitching is a way to combine multiple GraphQL schemas under a
single endpoint, so that clients can request data from different APIs
in a single query. It also allows to add links between these schemas
to e.g., automatically resolve references to actual types.

This first implementation was made with the following goals/limitations
in mind:

- I tried to avoid interfering with existing code and to stick to
  existing architecture where possible
- I tried to avoid introducing new dependencies for existing users of
  the library; in particular, kgraphql core should not get any ktor
  specific dependencies
- I tried to have the stitching API as lean as possible
- I focused on the non-experimental `ParallelRequestExecutor` first

Over the course of implementing schema stitching, several bugs were
resolved on the way but schema stitching is currently still impacted
by some major issues like incomplete error handling (#114) that need
to be addressed separately.

Resolves #9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant