)]}'
{
  "commit": "e2a59c531fbacd7ea16acdabb548fc2dcdca23f0",
  "tree": "c8701f6018b64ab40a39866508a3945f10e50612",
  "parents": [
    "9a940a0830c09a40fd5521f66ed6999a6f24e2c4"
  ],
  "author": {
    "name": "Filip Filmar",
    "email": "fmil@fuchsia.infra.roller.google.com",
    "time": "Mon May 19 14:04:59 2025 -0700"
  },
  "committer": {
    "name": "Copybara-Service",
    "email": "copybara-worker@google.com",
    "time": "Mon May 19 14:06:49 2025 -0700"
  },
  "message": "[roll] Roll fuchsia [starnix][hrtimer] Attempt to resolve flakiness in interval timer handling.\n\nThere is a long-standing flakiness in the test infra of the test\nsysfs_power_tests.cm, for which I only recently found a plausible\nreason. The symptom is that interval timers stop firing, in a\nnon-deterministic way, while they are expected to be firing.\n\nNow, it is hard to verify that the particular sequence of events shown\nbelow is causing the observed flakiness. We\u0027ll verify by watching the\nflaky test behavior over time. This change does fix three real\nidentified issues, a claim which is confirmed by the included regression\ntests. Whether the fixes will also remove the observed test flakiness in\ntest infra remains to be seen.\n\nOne problem sequence of events is as follows:\n\n1. Initial: timer heap is empty. Sleeps are allowed.\n2. Starnix schedules an interval timer T. Sleeps are allowed.\n3. T fires. The container wakes. Sleeps are not allowed while T\u0027s wake\n   proxy message is being processed.\n4. HR Timer Manager removes T from the timer heap. Since T an interval\n   timer, sleeps are NOT allowed as we want to wait until T is\n   rescheduled. T is not rescheduled yet. Heap is empty.\n5. Starnix schedules another timer T2. Since T2 is not interval, sleeps\n   are now allowed. T is still not rescheduled.\n6. T2 expires. Hr Timer Manager removes T2 from the timer heap. Heap is\n   now empty. Since T2 is not interval timer, the\n   mark_all_proxy_messages_handled is run, and sleeps are now allowed. T\n   is still not rescheduled.\n7. Container is suspended, without any scheduled alarms. T is never\n   rescheduled.\n\nThe fix consists in keeping active track of interval timers which are in\nthe state of \"have just fired, but not rescheduled yet\". Having such\ntimers should prevent suspend until a new timer is scheduled.\n\nMore generally, we should not allow a Starnix container to be suspended\nif there are any timers we know of which should be scheduled but are\nnot. Instead, we should keep the container running until those timers\nget scheduled. The previous code handled this only for the last interval\ntimer that fired, and only on expiry, which does not cover all the\npossible event interleavings. This issue was then eventually causing\nobservable infra test flakes.\n\nThis change seems like it could remove infra test flakes\nhr_timer_manager.rs, since it fixes behaviors that should be very\nadjacent to the problem behavior we observed. However, I remain cautious\nabout claiming that it\u0027s a fix, since I had a few unsuccessful attempts\nbefore.\n\nMultiply: starnix-tests\nTested: locally\nOriginal-Bug: 373731551\nOriginal-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1277836\nOriginal-Revision: 50b2eb2365744bfcff64e142b114beefb6c63f24\nGitOrigin-RevId: f3d47786124dae52c6d8581af56b7794eef40907\nChange-Id: Ic81753bce5966cb53a7319cc41382c5172ac48ee\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "1ee175446f4db21b2856bd8192ca72215779a920",
      "old_mode": 33188,
      "old_path": "stem",
      "new_id": "06f476860a0c6fd067926da93d758c7bd110c35d",
      "new_mode": 33188,
      "new_path": "stem"
    }
  ]
}