-
-
Notifications
You must be signed in to change notification settings - Fork 144
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
Fix autoreset_control_seconds_test on dev HA core #733
base: main
Are you sure you want to change the base?
Conversation
This line resets the timer: Somehow on the dev branch there is a slowdown. Locally these steps take 16 ms. ¯_(ツ)_/¯ From failing CI:
from working version locally:
|
@bdraco, sorry to tag you here on a random repo, however, but I thought you might want to know this since you have been working on performance optimizations for a long time now. I think in the latest In Adaptive Lighting are keeping an async timer that counts down from a In this loop adaptive-lighting/tests/test_switch.py Lines 798 to 803 in 5b7ee44
we call This works fine in any released version of Home Assistant since 2022.11, however, in the latest |
I can't replicate this behavior. Can you bisect to a specific commit causing it? |
Unfortunately, I can’t reproduce it locally either (on my Mac). Just happens in CI. I’ll try to bisect via CI if I can make the failure happen reliably. |
edit: for some reason, the exact tagged commit works (2023.7.3) but the commits before and after do not. So still checking what's going on. |
abc7ebd
to
11c4d72
Compare
@bdraco, I ran ≈1000 CI jobs (🤯) trying to pinpoint exactly where the test starts failing. My hypothesis is now that it happened on 3a06659120aa629e0db290ec9e83e2ad129baaf3 (home-assistant/core#96729). To test this I ran 5 jobs with that commit and 5 jobs with the parent commit c76fac0633749e8f463f9b6c22a4d47bba5ba1e7. In that job the former commit fails consistently and the later always passes. |
That would make sense if you are missing some await hass.async_block_till_done()s in your tests |
This turned into a complete mystery to me. I am calling Some how the problem disappears when I add logging statements at some places.
which is the I will just remove this part of the test because I am also not able to repro locally. |
So these two messages are in the logs (which take 50-100ms in failure cases):
Which means that in |
I feel like I remember this happening back in April. Probably a different scenario, but I could have sworn it was the exact variable name |
Turns out that there is a slowdown in the dev version and somehow the loop takes 0.1 seconds in dev.