Skip to content

Encapsulate checking for GraphQL error (part 2)

Brett Walker requested to merge bw-graphql-encapsulate-error-expects-2 into master

What does this MR do and why?

When migrating to the new GraphQL runtime interpreter (#210556 (closed)), GraphQL errors/exceptions that are raised, for example in resolvers https://gitlab.com/gitlab-org/gitlab/blob/master/app/graphql/resolvers/concerns/time_frame_arguments.rb#L39, are no longer propagated as exceptions, but as the actual error object.

In particular, GraphQL::ExecutionError and it's subclasses, such as Gitlab::Graphql::Errors::ArgumentError, Gitlab::Graphql::Errors::ResourceNotAvailable, and Gitlab::Graphql::Errors::MutationError are now caught at https://github.com/rmosolgo/graphql-ruby/blob/a4cfb6a391d64b6912440c075eb3236e36c28f5f/lib/graphql/schema/field.rb#L725, which simply returns the error object rather than raising it.

Currently our specs have checks like this

expect { resolve_scope }.to raise_error(Gitlab::Graphql::Errors::ResourceNotAvailable)

which now need to get changed to (for the new interpreter)

expect(resolve_scope).to be_instance_of(Gitlab::Graphql::Errors::ResourceNotAvailable)

The creation of expect_graphql_error_to_be_created(error_class, match_message = nil) allows us to make these changes in the current code base, and provide a different version for the upcoming code.

Related #210556 (closed)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Brett Walker

Merge request reports