Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make steeringWheelPosition and windowHeatingState optional #323

Merged
merged 2 commits into from
Jan 13, 2025

Conversation

prvakt
Copy link
Collaborator

@prvakt prvakt commented Jan 10, 2025

@prvakt prvakt added the bug Something isn't working label Jan 10, 2025
@prvakt prvakt requested a review from WebSpider January 10, 2025 10:57
Copy link
Contributor

@WebSpider WebSpider left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will do what's needed, but do we want to catch and model all error-states from API?
with "state" being "INVALID", this is clearly an error state.

Maybe it is a better idea to let the library throw a proper MySkoda.SerializationError exception in cases like this, so we can generally handle this in the integration and tell the user "whelp, we got a SerializationError and the state is INVALID, so something is wrong with MySkoda servers 🤷 "

@prvakt
Copy link
Collaborator Author

prvakt commented Jan 10, 2025

This will do what's needed, but do we want to catch and model all error-states from API? with "state" being "INVALID", this is clearly an error state.

Maybe it is a better idea to let the library throw a proper MySkoda.SerializationError exception in cases like this, so we can generally handle this in the integration and tell the user "whelp, we got a SerializationError and the state is INVALID, so something is wrong with MySkoda servers 🤷 "

Rest of the data from that class is already using Default = None so why not these 2?

I agree that #548 was probably caused by problem on MySkoda side, but response still contains some usable data (timers have been returned) so why to throw it away?

@WebSpider
Copy link
Contributor

Rest of the data from that class is already using Default = None so why not these 2?

I agree that #548 was probably caused by problem on MySkoda side, but response still contains some usable data (timers have been returned) so why to throw it away?

Well, i guess the question is: If the API response indicates it's status is invalid, do we still trust the content of it?

Let's go with this for now, but it may need to.change in the future.

I agree we shouldnt change behaviour completely based on one occurance.

Copy link
Contributor

@WebSpider WebSpider left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm

@prvakt prvakt merged commit 3418105 into skodaconnect:main Jan 13, 2025
2 checks passed
@prvakt prvakt deleted the make-all-ac-sensors-optional branch January 13, 2025 08:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants