Build the cookie jar only on use and drop its deferral Proc

[ericproulx]

Makes the response-cookie path lazy at the request boundary, in two related steps.

1. Build the jar only when a cookie is touched

Grape::Endpoint#build_response_cookies runs on every request and delegated response_cookies → cookies → request.cookies, materializing the Grape::Cookies jar even when the handler never touched a cookie (the jar's response_cookies then immediately no-ops). Gate it on a new Grape::Request#cookies? predicate, true only once the jar exists:

def build_response_cookies
  return unless request.cookies?
  ...
end

A Set-Cookie is only ever emitted after a cookies[...] = write, which always materializes the jar first — so cookies? is true exactly when there could be something to flush. Behaviour is unchanged; a cookie-free request now allocates no jar.

2. Drop the jar's deferral Proc

The -> { rack_cookies } Proc existed (since #2549) to defer the request-cookie parse, because the jar used to be built on every request. Now that step 1 only builds it when a cookie is actually read or written — and any access forces the parse immediately (a write via []= always did) — the Proc no longer earns its keep. Parse rack_cookies eagerly in the constructor and replace the is_a?(Proc) lazy reader with a plain attr_reader, dropping the closure allocation and a per-access branch.

The ActiveSupport::HashWithIndifferentAccess wrapping is unchanged — it backs Grape's string/symbol-indifferent cookie access (set_cookie username=… is read back as cookies[:username]).

Result

A request that never touches a cookie now allocates zero Grape::Cookies/Proc objects (was ~10 on the flush path); a cookie-using request loses the extra Proc closure and the per-access is_a?(Proc) check.

Tests

spec/grape/endpoint_spec.rb #cookies — 5 examples, 0 failures (set / update / delete / symbol-keyed read / "does not set response cookies"). Rubocop clean.

🤖 Generated with Claude Code

[github-actions]

Danger Report

No issues found.

View run