secondEmail field minLength constraint rejects valid empty strings from API

[jasonhernandez]

Summary

The secondEmail field in UserProfile and IdentitySourceUserProfileForUpsert schemas has a minLength: 5 constraint, but the Okta API returns empty strings ("") for users without a secondary email. This causes SDK validation failures when deserializing valid API responses.

Affected Schemas

In dist/current/management-minimal.yaml:

1. UserProfile.secondEmail (lines 81080-81087)
2. IdentitySourceUserProfileForUpsert.secondEmail (lines 66790-66796)

Current Definition

secondEmail:
  type: string
  format: email
  minLength: 5
  maxLength: 100
  nullable: true

Expected Definition

secondEmail:
  type: string
  format: email
  maxLength: 100
  nullable: true

Reproduction

1. Create a user in Okta with no secondary email (or with secondEmail set to empty string)
2. Use any SDK generated from this spec (e.g., okta-sdk-python) to list users
3. SDK throws validation error when deserializing the response

Example error from Python SDK (Pydantic):

1 validation error for UserProfile
secondEmail
  String should have at least 5 characters [type=string_too_short, input_value='', input_type=str]

Related SDK Issues

• secondEmail field validation is too strict. okta-sdk-python#477
• Pydantic Models Reject Valid Empty String Values okta-sdk-python#481

Suggested Fix

Remove minLength: 5 from secondEmail fields. The format: email constraint is sufficient for validating non-empty email values, and empty strings should be allowed for nullable optional fields.