[Bug] CandlestickApi.candles returns empty/None fields while raw API calls work correctly #119
Description
There is a critical discrepancy between the raw API response and the behavior of the lighter-python SDK. While direct API calls (via curl or browser) return the expected candle data, the CandlestickApi.candles method in this library returns a Candles object with None or empty fields.
Observations
Raw API Response (via curl): SUCCESSFUL.
The server returns the correct JSON structure with all data populated (e.g., code: 200, r: "1m", and the list c containing candle objects).
SDK Response (via lighter-python): FAILED.
The Candles object is instantiated, but its attributes (like .c) are missing data or remain None because the parser fails to map the JSON correctly.
Root Cause: Property Name Collision in OpenAPI Spec
The issue is caused by a naming conflict in the candles.py model that originates from the OpenAPI specification:
Top-level Collision: In the Candles model, the field containing the list of candle objects is named c.
Nested Collision: In the Candle (item) model, the field for "Close Price" is also named c.
When the SDK attempts to parse the response:
It encounters the top-level key c.
Due to the naming collision and the way the models are generated (using model_construct and from_dict), the Pydantic parser fails to disambiguate the "List of Candles" from the "Close Price" field.
Consequently, the data is either dropped or misassigned to additional_properties.
Evidence
In lighter/models/candles.py:
Python
L26: The list is named 'c', which conflicts with the 'c' (close price) in individual candles
c: List[Candle] = Field(description=" candles")
Suggested Fix
The OpenAPI specification must be updated to avoid using the same identifier c for different structural levels:
Recommended: Rename the c property in the Candles schema to data or candles.
Alternative: Explicitly map the fields using unique aliases during the code generation process to prevent Python attribute collision.