Model#initialize drops every `false` value — booleans are silently lost on requests and responses
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 88/100
Research direction
Start with lib/auth0/internal/types/model.rb and reproduce the request and response examples using Auth0::Users::Types::UpdateUserRequestContent and Auth0::Types::UpdateUserResponseContent. Verify that false values remain present in to_h, are returned by readers after load, and that fields with default: false also use their defaults.
Written by the indexing model from the issue text.
Description
Describe the problem
Auth0::Internal::Types::Model#initialize resolves each declared field with ||, so a legitimate false is treated as absent and never reaches @data. Since #to_h only emits keys present in @data, every boolean whose value is false silently disappears — on requests and responses alike.
Requests: users.update(id:, blocked: false) builds an empty PATCH body, and Auth0 rejects it with 400 Payload validation error: 'None of the valid schemas were met'. Unblocking a user is not possible through the SDK.
Responses: a user who genuinely is "email_verified": false deserializes to nil, indistinguishable from "the API did not return this field". This one is quiet — no exception, just a wrong value.
Reproduction
require "auth0/version" # still needed on 6.2.0, see #786
require "auth0"
k = Auth0::Users::Types::UpdateUserRequestContent
k.new(id: "auth0|abc", blocked: false, email_verified: false).to_h
# => {"id" => "auth0|abc"} # both booleans dropped
k.new(id: "auth0|abc", blocked: true).to_h
# => {"id" => "auth0|abc", "blocked" => true} # true survives
json = '{"user_id":"auth0|abc","email":"[email protected]","email_verified":false,"blocked":false}'
u = Auth0::Types::UpdateUserResponseContent.load(json)
u.email_verified # => nil (expected false)
u.blocked # => nil (expected false)
u.to_h # => {"user_id" => "auth0|abc", "email" => "[email protected]"}
Users::Client#update does request_data.except("id"), so the first case sends PATCH /api/v2/users/auth0|abc with a literal {} body.
Expected behaviour
false round-trips like any other value: to_h includes the key and the reader returns false.
Cause
lib/auth0/internal/types/model.rb:
value = values.delete(field.api_name.to_sym) || values.delete(field.api_name) || values.delete(field_name)
field_value = value || (if field.literal?
field.value
elsif field.default
field.default
end)
Both || chains discard false. Presence has to be decided with Hash#key?, and the literal/default fallback should apply only when the value is genuinely nil:
key = [field.api_name.to_sym, field.api_name, field_name].find { |k| values.key?(k) }
value = key.nil? ? nil : values.delete(key)
field_value =
if !value.nil?
value
elsif field.literal?
field.value
else
field.default
end
(Also note the elsif field.default guard is itself truthiness-based, so a field declared with default: false can never fall back to its default either.)
Because this lives in the shared base model it affects every boolean in the generated API surface — blocked, email_verified, verify_email, phone_verified, include_totals, and so on.
Environment
- auth0 6.2.0 —
lib/auth0/internal/types/model.rbis byte-identical in 6.0.0, 6.1.0 and 6.2.0 (md50908fa9ec6636316bc78688d3e7436b3), so all three are affected - Ruby 3.4
- Dominant language
- Ruby
- Stars
- 205
- Forks
- 148
- Avg merge
- 13h
- Merged PRs (30d)
- 4
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from auth0/ruby-auth0
-
feature request
Difficulty 3/5 1-2 days Newbie friendliness 45/100
auth0/ruby-auth0#709 ·
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 50/100
auth0/ruby-auth0#610 · 1 comment ·
-
feature request
Difficulty 5/5 Over a week Newbie friendliness 32/100
auth0/ruby-auth0#606 · 2 comments · 1 reaction ·
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 35/100
auth0/ruby-auth0#556 · 2 comments ·
-
feature request
Difficulty 3/5 1-2 days Newbie friendliness 35/100
auth0/ruby-auth0#500 · 1 comment ·
All issues in auth0/ruby-auth0
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
data error
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
riscv/riscv-unified-db#2648 ·
Maintainers usually reply within 1 day
-
P2 testing
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day