models: add named integer enum types - #178
mihaimarcu2004 wants to merge 1 commit into
Conversation
…in mode, pool status, RFQ direction)
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| @field_validator('account_type') | ||
| def account_type_validate_enum(cls, value): | ||
| """Validates the enum""" | ||
| if value not in set([0, 1, 2, 3, 4, 5]): | ||
| raise ValueError("must be one of enum values (0, 1, 2, 3, 4, 5)") | ||
| return value |
There was a problem hiding this comment.
🟡 Valid integer values rejected by models
When Account receives an unlisted integer account type, account_type_validate_enum rejects it. The schema allows integers without an enum restriction, so valid model construction and assignment fail. Other new validators impose the same restriction on trading modes, margin modes, pool statuses, and RFQ directions.
Learn more
The bundled OpenAPI schema declares these fields as integers rather than enumerations. A named constant can describe known values without changing the accepted value range. The new validators run for direct Pydantic construction and assignment, while the generated from_dict path uses model_construct and does not invoke them. This makes construction reject integers that the SDK previously accepted and that the schema still permits. The same restriction appears on the new validators in DetailedAccount, AccountPosition, MarketConfig, PublicPoolInfo, PublicPoolMetadata, and the RFQ response and entry models.
Example: A caller creates an Account with account_type=6 after the service adds a new account type. The bundled integer schema accepts 6, but direct construction raises ValidationError; Account.from_dict accepts the same value.
Recommended fix: Keep the named enum classes as optional constants but remove the closed-set validators until the API contract itself declares closed enum values. If the API contract is intentionally closed, update the OpenAPI schemas and regenerate all affected SDK models together.
Was this helpful? React with 👍 or 👎 to provide feedback.
| @classmethod | ||
| def from_json(cls, json_str: str) -> Self: | ||
| """Create an instance of AccountAccountTypeEnum from a JSON string""" | ||
| return cls(json.loads(json_str)) |
There was a problem hiding this comment.
🟡 Noninteger JSON becomes a valid enum
When AccountAccountTypeEnum.from_json receives true or 1.0, it returns Sub instead of rejecting noninteger JSON. All added enums use the same conversion, silently misclassifying malformed values.
Learn more
Every added integer enum calls its constructor on the result of json.loads. In Python, True == 1 and 1.0 == 1, so integer enum lookup accepts both and returns the member with value 1. These enum classes represent integer JSON fields; the model fields themselves use StrictInt for the same properties.
Example: AccountAccountTypeEnum.from_json('true') returns AccountAccountTypeEnum.Sub, although true is a JSON boolean, not account type 1.
Recommended fix: Parse JSON and require type(value) is int before converting it to an enum member. Apply this check consistently across all new enum from_json implementations.
Was this helpful? React with 👍 or 👎 to provide feedback.
| account_type: StrictInt = Field(description="See AccountAccountTypeEnum") | ||
| account_trading_mode: StrictInt = Field(description="Classic=0 and Unified=1. See AccountAccountTradingModeEnum") |
There was a problem hiding this comment.
🔍 Response fields remain plain integers
The new enum classes do not change StrictInt model fields. API responses still expose integers, not members with .name; clarify whether the enums are only intended as constants.
Was this helpful? React with 👍 or 👎 to provide feedback.
| Simple = 0 | ||
| Unified = 1 |
There was a problem hiding this comment.
🔍 Trading mode zero has two names
The enum calls mode 0 Simple, while the account field description calls it Classic. Clarify which public name consumers can rely on.
Was this helpful? React with 👍 or 👎 to provide feedback.
2 participants
Uh oh!
There was an error while loading. Please reload this page.