rescue_from handler return values during argument coercion are passed to resolve as the argument's value
I maintainer di solito rispondono entro 1 giorno
Una pull request collegata è già stata integrata.
- #5837 di @austinjb32 — integrata
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 58/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- ruby
- Ambito
- backend-api-design
Direzione di ricerca
Start in Schema::Argument#coerce_into_values and trace the three handle_or_reraise call sites, then check how coerce_arguments and Runtime#evaluate_selection_with_args handle errors. Reproduce with the provided schema and argument validation example. Done means a returned GraphQL::ExecutionError reaches the response as the expected error and the resolver does not receive it as an argument; add a regression test for that behavior.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Describe the bug
When an error is raised during argument coercion — e.g. an argument validates: check failing inside Schema::Argument#prepare_value — the error is routed through handle_or_reraise, and the schema's rescue_from handler's return value is stored as the argument's value. If the handler returns a GraphQL::ExecutionError (a very common pattern), that error object is passed to the field's resolver as the argument value instead of short-circuiting resolution with the error.
Runtime#evaluate_selection_with_args only short-circuits when resolved_arguments itself is an ExecutionError/UnauthorizedError — errors nested inside the Arguments object sail through.
Versions
graphql 2.6.13 (also reproduced on 2.5.11)
Steps to reproduce
require "graphql"
class LeakySchema < GraphQL::Schema
# Common pattern: rescue_from returns (rather than raises) an error object
rescue_from(StandardError) do |err, _obj, _args, _ctx, _field|
GraphQL::ExecutionError.new(err.message)
end
class Query < GraphQL::Schema::Object
field :check, Integer, null: true do
argument :limit, Integer, validates: { numericality: { within: 1..50 } }
end
def check(limit:)
limit + 1
end
end
query(Query)
end
pp LeakySchema.execute("{ check(limit: 0) }").to_h
Expected behavior
{"errors" => [{"message" => "limit must be within 1..50", ...}], "data" => {"check" => nil}}
Actual behavior
resolve receives the GraphQL::ExecutionError instance as limit, so limit + 1 raises NoMethodError, which the handler then converts into a misleading error:
{"errors" => [{"message" => "undefined method '+' for an instance of GraphQL::ExecutionError", ...}]}
Without any rescue_from handler, the error reraises and surfaces correctly — so this only reproduces on schemas that register a handler which returns an error object. (It also makes the behavior environment-dependent if the handler is registered conditionally, e.g. only outside development.)
Diagnosis
Schema::Argument#coerce_into_values rescues coercion errors via context.schema.handle_or_reraise(context, err) at all three call sites (type.coerce_input, prepare_value, load_and_authorize_value) and assigns the return value as the argument value:
prepared_value = begin
prepare_value(parent_object, resolved_coerced_value, context: context)
rescue StandardError => err
context.schema.handle_or_reraise(context, err) # <= a returned error object lands here
end
coerce_arguments correctly handles raised errors (finished_args = err → continue_value), but nothing handles handler-returned ones.
Possible fix
Re-raise the handled result when it's an error object, so coerce_arguments short-circuits with it — I've got a working branch with a failing test + fix here if useful: https://github.com/austinjb32/graphql-ruby/tree/fix-argument-validation-error-leak
Additional context
Same bug family as the historical prepare:-returns-error leak (#1024).
- Lingua principale
- Ruby
- Stelle
- 5.4k
- Fork
- 1.4k
- Merge medio
- 1g 8h
- PR unite (30g)
- 74
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di rmosolgo/graphql-ruby
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
rmosolgo/graphql-ruby#5843 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
rmosolgo/graphql-ruby#5763 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
rmosolgo/graphql-ruby#5761 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
rmosolgo/graphql-ruby#5707 · 10 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 30/100
rmosolgo/graphql-ruby#5655 · 4 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di rmosolgo/graphql-ruby
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
hashicorp/homebrew-tap#433 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 62/100
TheOdinProject/curriculum#31509 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
GPX export ignores set datesAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
dependencies Difficulty: Easy Good First Issue
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
rubyforgood/casa#7325 ·
I maintainer di solito rispondono entro 1 giorno