SPOT : UserDataStreamEventsResponse does not deserialize correctly, instance is always None

Inizia con UserDataStreamEventsResponse.model_validate e i relativi modelli concreti degli eventi, quindi confronta il comportamento dell’unione discriminata con il problema SymbolFilters in #476 e il problema correlato #405. Il lavoro è completo quando un evento come balanceUpdate produce un’istanza di evento tipizzata e conserva i suoi campi invece di lasciare actual_instance come None.

Description

The UserDataStreamEventsResponse model fails to parse user data stream events into their concrete event types (BalanceUpdate, ExecutionReport, OutboundAccountPosition, EventStreamTerminated, etc.). All input results in None and the event data is completely lost.

Expected Behavior

When validating a user data stream event, the model should:

1. Parse the event dictionary into the appropriate concrete event type based on the "e" field
2. Return a strongly-typed instance (e.g., BalanceUpdate, ExecutionReport)
3. Preserve all event data fields

Example:

from binance_sdk_spot.websocket_api.models import UserDataStreamEventsResponse

event = {
    "e": "balanceUpdate",
    "E": 1573200697110,
    "a": "BTC",
    "d": "100.00000000",
    "T": 1573200697068
}

result = UserDataStreamEventsResponse.model_validate(event)
# Expected: result is a BalanceUpdate instance with all fields accessible
# Expected: result.a == "BTC"
# Expected: result.d == "100.00000000"
# Expected: result.E == 1573200697110
# Expected: result.e == "balanceUpdate"
# Expected: result.T == 1573200697068

Actual Behavior

The parsing always fails and returns None, losing all event data:

result = UserDataStreamEventsResponse.model_validate(event)
# Actual: result.actual_instance is None
# Actual: All event data is lost
# Actual: Cannot access event fields

Possible Root Cause

The model uses Pydantic's discriminated union pattern but fails to properly discriminate between event types. Issues include:

1. Schema Validation Failure: The discriminator field or schema mapping is not correctly configured
2. Type Resolution Failure: The model cannot resolve which concrete event type to instantiate
3. Silent Failure: Instead of raising validation errors, it silently returns None

This is similar to the SymbolFilters discriminated union issue that was previously identified, where filter type discrimination failed.

Impact

• Complete Data Loss: All user data stream events are lost when using this model
• No Balance Updates: Balance changes from outboundAccountPosition events cannot be processed
• No Order Updates: Order status changes from executionReport events cannot be tracked
• No Stream Monitoring: Stream termination events cannot be detected

Related Issues

• Similar to #476 discriminated union parsing issue

References

Affected Version: >=2.1.0
Related or same as #405