Validate required Hash params scopes without the attributes iterator

[ericproulx]

Summary

Most validators of most endpoints sit on the root params scope or a required Hash scope under it, and for them Validators::Base ran the generic machinery: scope.should_validate?, which resolves the scope's params and walks the parent chain, then an AttributesIterator pass that resolves the params again, checks for arrays and the empty-optional sentinel and yields once per attribute, then a block that re-checks the scope's requiredness and dependency. For a root-scope validator that plumbing took about 570 of its 840 ns; a nested one paid more.

When a scope and every one of its ancestors is required and depends on nothing, should_validate? is true for every request and has no side effects. ParamsScope#always_validated? answers that. If the scope also does not iterate elements and its params resolve to a Hash, the iterator path reduces to: for each attribute, validate_param!(attr, params) if it is required or present. So:

• #validate skips should_validate? for such a scope.
• #validate! resolves the scope's params once and runs that loop (#validate_attributes!).
• Array scopes, given, optional scopes and their descendants, and params that resolve to something other than a Hash keep the existing path. DefaultValidator and the multiple-params validators, which override #validate!, only skip should_validate?.
• The flag is set in #initialize, since validators are frozen once built; a scope's parent, optionality, dependency and type are fixed before its block declares anything.

Per validator: root presence 658 → 311 ns, root coerce 728 → 406 ns, nested coerce 1.77 → 1.02 µs.

Benchmarks

Median of 7 interleaved subprocess rounds against master, Ruby 4.0.6, no JIT:

request	delta
JSON POST, 5 typed root params	+20.5%
JSON POST with a required nested Hash (3 attributes)	+19.3%
GET, 3 query params	+11.5%
GET, pagination helper with values and defaults, mutually_exclusive (10 validators)	+11.1%
POST returning declared(params), optional nested Hash	+6.5%
GET with a before filter and a typed route param	+4.4%
GET with no params (control)	+0.2% (noise)

Under YJIT, an earlier root-only version of this measured +11.3% on the JSON POST, +12.0% on the 10-validator GET and +7.3% on the 3-param GET.

Missing spec, added

An Array group handed a Hash reports only its own type error; its members are not validated against the Hash as though it were one element. Nothing pinned that: sending such a scope down the new path passed the whole suite while adding items[id] is missing to the error. The new spec passes before and after this change and fails in that case.

Behaviour

Byte-identical to master over a 104-case validation matrix, under both the HashWithIndifferentAccess and Hash params builders: every built-in validator (values, except_values, regexp, length, same_as, allow_blank, default, as, mutually_exclusive, all_or_none_of, at_least_one_of, given, fail_fast, a custom validator), required and optional nested Hashes three levels deep, a with group inside a nested Hash, a String or an Array sent where a Hash is declared, a Hash sent for an Array group, and type: JSON given a Hash, an Array and garbage. The routing and coercion matrices are unchanged too.

Test plan

• Full RSpec suite passes locally.
• RuboCop clean.
• Mutation-checked: the loop ignoring required? fails 29 specs; ignoring whether the key is present, 6; taking the new path for every scope, 74; stopping at the first error, 2; skipping should_validate? for every scope, 6; always_validated? ignoring optionality, 7; ignoring the parent chain, 1; taking the new path for array scopes, 1 (the new spec); dropping the Hash guard, 2.
• CI green.

🤖 Generated with Claude Code

[github-actions]

Danger Report

No issues found.

View run

[ericproulx]

Closing in favour of #2936, which combines #2922–#2934 into one PR, re-benchmarked as a whole against master. The write-up here (behaviour matrix, mutation results) still describes this part of the change.