ruby-grape / grape / 34770584299

99%

push

github

Speed up error responses, param defaults and deciding whether to read a request body (#2939)

Three request-path changes, each giving the same answers as before:

- The entity lookup behind `present` without `with:`, and behind every
  error response the error formatter renders, walked the object's
  ancestors asking each one for an `Entity` constant of its own.
  `klass.const_defined?(:Entity)` answers for the whole chain in one call,
  so a class nothing on the chain names an Entity for -- a String or Hash
  error message, most presented objects -- skips the walk. It also looks
  on Object, which the walk passes over, so a top-level ::Entity only
  sends the lookup on to the walk.

- DefaultValidator always went through the attributes iterator. On a
  scope that is always validated and does not iterate elements, once its
  params resolve to a Hash, the iterator's per-attribute checks come down
  to whether the value is missing, as Base#validate_attributes! already
  relies on for the other validators.

- The formatter asked Rack's form_data? and parseable_data? whether to
  read a body and then the media type to pick a parser: three parses of
  CONTENT_TYPE, two of them paid by a POST or DELETE with no body before
  it found nothing to read. It now checks the method and the body's
  presence off the env first, parses the media type once and tests it
  against Rack's FORM_DATA_MEDIA_TYPES and PARSEABLE_DATA_MEDIA_TYPES.
  That is the same answer: form_data?'s other branch needs a nil media
  type, which Rack only returns when CONTENT_TYPE is missing or empty.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

1353 of 1399 branches covered (96.71%)

Branch coverage included in aggregate %.

15 of 15 new or added lines in 3 files covered. (100.0%)

4115 of 4115 relevant lines covered (100.0%)

26628.62 hits per line