Behavior is inconsistent between "flat" and nested schema when an exception occur.
To reproduce
NestedSchema = Dry::Schema.Params do
required(:value).filter(format?: /^\d+$/).value(:float)
end
ParentSchema = Dry::Schema.Params do
required(:data).hash(NestedSchema)
end
# KO: filter() should fail as it expect a string, got no exception
ParentSchema.call({data: {value: 123}})
=> #<Dry::Schema::Result{:data=>{:value=>123.0}} errors={} path=[]>
Expected behavior
I would expect the exception to be forwarded from the nested schema and not silenced as it is the case with a "flat" schema:
FlatSchema = Dry::Schema.Params do
required(:data).hash do
required(:value).filter(format?: /^\d+$/).value(:float)
end
end
# OK: filter() fails as it expects a string and gets a numeric -> exception
FlatSchema.call({data: {value: 123}})
=> [..]/.gem/ruby/3.0.2/gems/dry-logic-1.5.0/lib/dry/logic/predicates.rb:226:in `match?': no implicit conversion of Integer into String (TypeError)
[...]
Additionaly we can wonder why the filter call fails if we provide a value that is actually matching the coercion.
My environment
Affects my production application: YES
Ruby version: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233)
OS: Fedora 37 beta [aarch64-linux]
Behavior is inconsistent between "flat" and nested schema when an exception occur.
To reproduce
Expected behavior
I would expect the exception to be forwarded from the nested schema and not silenced as it is the case with a "flat" schema:
Additionaly we can wonder why the
filter
call fails if we provide a value that is actually matching the coercion.My environment
Affects my production application: YES Ruby version: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) OS: Fedora 37 beta [aarch64-linux]