Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Model#initialize drops every `false` value — booleans are silently lost on requests and responses

Cerrado Apto para principiantes
  • ¿Algo no está bien?
#800 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@kishore7snehil ya está trabajando en esto.

Desde el 7/10/2026.

  • #811 de @kishore7snehil — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
88/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
ruby
Área
api, backend

Línea de trabajo

Comienza con lib/auth0/internal/types/model.rb y reproduce los ejemplos de request y response usando Auth0::Users::Types::UpdateUserRequestContent y Auth0::Types::UpdateUserResponseContent. Verifica que los valores false permanezcan presentes en to_h, que los readers los devuelvan después de load y que los campos con default: false también usen sus valores predeterminados.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.rb is byte-identical in 6.0.0, 6.1.0 and 6.2.0 (md5 0908fa9ec6636316bc78688d3e7436b3), so all three are affected
  • Ruby 3.4
Lenguaje dominante
Ruby
Estrellas
205
Forks
147
Merge medio
16 h 2 min
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de auth0/ruby-auth0

Todos los issues de auth0/ruby-auth0

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.