fix: handle nullable discriminator fields in JWKS models

[BinoyOza-okta]

Fix: Handle Nullable Discriminator Fields in JWKS Models

Summary

This PR fixes JWKS (JSON Web Key) deserialization failures when the Okta API returns null values for fields that were incorrectly marked as required in the OpenAPI specification. The fix is template-based to ensure it persists through SDK regeneration.

Problem

Customers reported that list_applications() would fail with:

ValueError: Failed to lookup data type from the field `use` in the input.

This occurred when JWKS keys in application credentials contained null values for fields like use, kid, or kty, which are common in real Okta API responses.

Solution

Template Changes (Permanent)

1. openapi/templates/model_generic.mustache

   • Added null discriminator handling in from_dict() method
   • Returns base class instance when discriminator is null instead of raising ValueError

2. openapi/api.yaml

   • Marked fields as nullable: true: created, lastUpdated, kty, alg, use, e, n
   • Removed these fields from required lists

Other Changes

• Updated documentation with [nullable] tags

Files Changed

Templates (Permanent):

• openapi/templates/model_generic.mustache
• openapi/api.yaml

Generated Models (Auto-regenerated):

• 30+ model files in okta/models/

Documentation:

• docs/OAuth2ClientJsonSigningKeyResponse.md
• docs/OAuth2ClientJsonWebKeyRsaResponse.md

Backward Compatibility

✅ 100% backward compatible

• Existing code with non-null values continues to work
• New code can now handle null values gracefully
• No breaking changes

Usage Example

Before (Broken):

apps = await client.list_applications()
# ValueError: Failed to lookup data type from the field `use`

After (Fixed):

apps = await client.list_applications()
# Works correctly even when JWKS keys have null fields