Fix a history stats bug when window and tracked state change simultaneously

[karwosts]

Proposed change

This change attempts to fix a bug in history stats which looks like the following:

If the sensor has a tracked window that changes in the same minute as the source sensor changes, it is possible that the sensor will fail to register the state change for future updates until the next time the sensor toggles.

So if you have a sensor that tracks the on-time of a sensor for the current day (midnight to midnight), and if that sensor changes from on->off in the first minute after the window shift (12:00->12:01am), before the history stats sensor updates, history stats will act as if that sensor never turned off and keep accumulating time until the sensor turns on and back off again.

There is some racyness here so it doesn't always happen, it depends what event happens first after the window reset, the history stats sensor update or the source sensor update.

The update is missed because on the state change event, history stats sees it is a new time window and queries the database for state history, but this query does not yet include the current state change that triggered the update.

Then in the next scheduled update of the history stats sensor, it calculates that it does not need to re-query the database, so it just keeps operating on the previously fetched history, which is missing the latest state change.

To fix this issue, when we query the database in response to a state changed event, push the state change event to the end of the list of recorded state events (this is already done in cases where we don't query the database).

I'm fairly sure this fixes the issue reported here: #75903 (comment), and maybe also #121535, but not sure.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[frenck]

Can we add tests for this case to show the problem and ensure it is solved?

../Frenck

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

[karwosts]

Without the fix the test fails here:

./tests/components/history_stats/test_sensor.py::test_state_change_during_window_rollover Failed: [undefined]AssertionError: assert '0.17' == '0.0'

[karwosts]

A new test has been added.

Fails on the original codebase and passes with the new bugfix.

[frenck]

Thanks, @karwosts 👍

../Frenck