Tell a missing root: from a malformed one

[VSN2015]

Third and smallest of the bug fixes from the same hunt (#21, #22).

The bug

permit_params :create, root: :user do
  required :name, :string
end

{ "user": "bob" }

answered:

{ "param": "user", "code": "missing" }

…for a key the client had just sent. That sends it looking in exactly the wrong place — the problem isn't that user is absent, it's that it isn't an object.

The fix

An absent root and a malformed one are different client mistakes, and now read differently:

Request	Code
{}	missing
{"user": null}	missing
{"user": ""}	missing
{"user": "bob"}	invalid_type
{"user": []}	invalid_type
{"user": 3}	invalid_type

Absence is decided by the gem's own permittable_absent?, so "" and null still read as missing rather than becoming a new kind of error — consistent with how every other field in the gem treats an empty value.

Nothing moves at the HTTP level

Both remain 400 — either way the envelope itself is malformed — so no client's status handling changes. Only the diagnostic gets accurate. invalid_type is already the code the gem uses for "this value can't be the declared shape", and it's already listed in the exported OpenAPI error schema, so consumers need no new vocabulary.

Verification

• 201 examples, 0 failures (2 new, written before the fix), covering all six shapes above
• The pre-existing spec asserting :bad_request for { user: "nope" } deliberately never asserted the code, so it still passes unchanged
• RuboCop clean

[VSN2015]

Review of PR #23: Clear diagnostic improvement. Distinguishing between a truly absent root (missing) and an incorrectly typed root (invalid_type) eliminates developer confusion while maintaining 400 Bad Request semantics.

[VSN2015]

permittable_absent?(value, raw, key) ? "missing" : "invalid_type" provides a much cleaner error report when a client sends {"user": "bob"} instead of misleadingly claiming the user key was omitted.