HealthITAU
Configurations with custom fields cause pydantic to choke
Hi,
When calling my configuration list for domain names it has custom fields in, and this seems to cause pydantic to choke.
Calling configuration = cwm.company.configurations.paginated(1,1000).params={'conditions': 'type/id=55'}
Traceback (most recent call last):
File "domain-expiry-refresh.py", line 38, in <module>
configuration = cwm.company.configurations.paginated(1,1000).params={'conditions': 'type/id=55'}
File "C:\Program Files (x86)\Python311-32\Lib\site-packages\pyconnectwise\endpoints\manage\CompanyConfigurationsEndpoint.py", line 91, in paginated
return PaginatedResponse(
File "C:\Program Files (x86)\Python311-32\Lib\site-packages\pyconnectwise\responses\paginated_response.py", line 55, in __init__
self._initialize(response, response_model, endpoint, page, page_size, params)
File "C:\Program Files (x86)\Python311-32\Lib\site-packages\pyconnectwise\responses\paginated_response.py", line 101, in _initialize
self.data: list[TModel] = [
File "C:\Program Files (x86)\Python311-32\Lib\site-packages\pyconnectwise\responses\paginated_response.py", line 102, in <listcomp>
response_model.model_validate(d) for d in response.json()
File "C:\Program Files (x86)\Python311-32\Lib\site-packages\pydantic\main.py", line 509, in model_validate
return cls.__pydantic_validator__.validate_python(
pydantic_core._pydantic_core.ValidationError: 2 validation errors for CompanyConfiguration
questions.0.answer
Input should be a valid dictionary [type=dict_type, input_value='configuration_custom_secret_value_1', input_type=str]
For further information visit https://errors.pydantic.dev/2.6/v/dict_type
questions.1.answer
Input should be a valid dictionary [type=dict_type, input_value='configuration_custom_secret_value_2, input_type=str]
For further information visit https://errors.pydantic.dev/2.6/v/dict_type
Hoping this isn't something too weird! I have removed the actual values that were returned as they were confidential and replaced it with configuration_custom_secret_value
yes, there are several endpoints that simply do not function due to valid bodies or resource paths getting rejected by the pydantic models. which i presume are generated based on connectwise' api spec. which frankly is unreliable based on my personal experience with those api docs. unfortunately, the maintainer doesnt seem to be active on this repo anymore.
I'm still here 😀 I actually have a PR ready for this that's still in testing. It's hard to find time for this when working on other work related projects. It was my hope that the community might assist in fixing these.
The issue is a pain - I can continue to bandaid the models or hand fix the API spec (which I've done for dozens of endpoints and models already...) but what happens when CW releases a new API version and the spec changes again? I've raised the API spec inconsistency issue with some higher ups at CW but it lost traction and they don't seem interested in fixing it.
The proper fix for this would be CW's API team doing their job properly, until then it's just a game of whack-a-mole.
I'm still here 😀 I actually have a PR ready for this that's still in testing. It's hard to find time for this when working on other work related projects. It was my hope that the community might assist in fixing these.
The issue is a pain - I can continue to bandaid the models or hand fix the API spec (which I've done for dozens of endpoints and models already...) but what happens when CW releases a new API version and the spec changes again? I've raised the API spec inconsistency issue with some higher ups at CW but it lost traction and they don't seem interested in fixing it.
The proper fix for this would be CW's API team doing their job properly, until then it's just a game of whack-a-mole.
I stand corrected! glad youre still around 😂.
Yes I know first hand what a losing battle that is. If you look at how long their spec has been inaccurate, the only logical conclusion one can come to is that they simply don't care.
@Yoshify would you consider an opt-in "unsafe" option for the api session object that could ignore pydantic validation?
@aescolastico have considered this, but it kind of goes against the whole reason I built it with pydantic validation in the first place, so not sure if I will. PRs are welcome though! :)