Skip to content

fix: log field-level execution exceptions with stack traces - #540

Merged
lukemurray merged 2 commits into
mainfrom
fix/log-field-execution-exceptions
Aug 3, 2026
Merged

lukemurray merged 2 commits into
mainfrom
fix/log-field-execution-exceptions

Conversation

@alex-birch

Copy link
Copy Markdown
Collaborator

Summary

  • Field-level failures returned as GraphQL errors (partial results in 6.x) now call ISchemaProvider.LogException, restoring the Error executing QueryRequest log with the original Exception / stack trace.
  • Adds LogException on ISchemaProvider (used by HandleException and field catch sites in ExecutableGraphQLStatement).
  • Regression test: FieldExecutionException_IsLoggedWithException.
  • Package version bump to 6.1.5.

Test plan

  • dotnet test --filter FullyQualifiedName~ErrorTests -f net8.0 (25 passed)
  • Confirmed new test failed before the fix (empty error logs), then passed after
  • CI green on this PR

Made with Cursor

alexbirch-xy and others added 2 commits August 3, 2026 15:29
Partial-result field failures were caught into GraphQL errors without
calling the schema logger, so Error executing QueryRequest (and the
exception stack) disappeared after the 6.x execution refactor. Log via
ISchemaProvider.LogException from field catch sites and HandleException.

Co-authored-by: Cursor <[email protected]>
…errors

- LogException gets a default (no-op) interface implementation. Adding a
  member without one breaks every custom ISchemaProvider, which a patch
  release should not do.
- It takes the field name and logs field failures under their own event id and
  message ("Error executing field 'x'", FieldError). Reusing the request-level
  message meant a query with several root fields could not say which one failed,
  and field errors could not be filtered from request errors.
- Document and validation errors are not logged. GenerateErrors returns their
  message to the caller in full, so nothing is being swallowed and the request,
  not the server, is what went wrong - logging every malformed query at Error is
  noise and is trivially remote-triggerable. Ones wrapping a real fault (inner
  exception set) are sanitised on the way out, so they are still logged, as are
  authorization failures (EntityGraphQLFieldException, not EntityGraphQLException).
- Test for that, and the existing one now asserts the field-named message.
- CHANGELOG entry trimmed and says it is a 6.0 regression.

Co-Authored-By: Claude Opus 5 <[email protected]>
@lukemurray
lukemurray merged commit dbf53cd into main Aug 3, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants