`schedule event at` when chained behaves oddly

[b1conrad]

These are the times for the bofm:verse_needed event:

2021-03-08T22:36:33.951
2021-03-08T22:37:34.351
2021-03-08T22:38:34.751
2021-03-08T22:39:35.162
2021-03-08T22:40:35.545
2021-03-08T22:41:35.967
2021-03-08T22:42:36.373
2021-03-08T22:43:36.788
2021-03-08T22:44:37.188
2021-03-08T22:45:37.570
2021-03-08T22:46:37.973
2021-03-08T22:47:38.409
2021-03-08T22:48:38.795
2021-03-08T22:49:39.311
2021-03-08T22:50:39.688
2021-03-08T22:51:40.069
2021-03-08T22:52:40.456
2021-03-08T22:53:40.828
2021-03-08T23:27:38.030
2021-03-09T00:10:07.829
2021-03-09T00:11:08.418
2021-03-09T00:12:08.807

Where the code is

  rule bofm_verse_needed {
    select when bofm verse_needed
    pre {
      v = bofm:verse();
    }
    fired {
      raise bofm event "schedule_bump";
      raise bofm event "verse_to_route" attributes v;
    }
  }
  rule bofm_schedule_bump {
    select when bofm schedule_bump
    fired {
      schedule bofm event "verse_needed" at time:add(time:now(), {"minutes": ent:minutes})
        setting(schedule_id);
      ent:schedule_id := schedule_id;
    }
  }

Notice that it stopped and then started again, twice. How does this happen?

ent:minutes is set to 1 and left unchanged throughout

[b1conrad]

Note that it did not stop, but has been going on for five or six more minutes at this point

[b1conrad]

The first thread never started again, although the schedule is still in the pico. So, I started a different one, and got this behavior:

2021-03-08T22:36:33.951
...
2021-03-08T22:53:40.828
2021-03-08T23:27:38.030
2021-03-09T00:10:07.829
...
2021-03-09T00:36:19.559
2021-03-09T01:15:20.280
2021-03-09T04:00:38.953
2021-03-09T05:18:12.929
...
2021-03-09T05:50:35.683

In the above, I used ellipsis when there were consecutive logs, to save vertical space. So, there are some very large gaps, but then it restarted. However, nothing that I have tried has gotten it going again.

[b1conrad]

Some (but not all) of the gaps coincide with moments that my laptop went into sleep mode.

[b1conrad]

The test case that I had been using had a flaw (unrelated but of some interest) in that it did an http:get between the time it woke up and the time it scheduled the next wake up call. That failed once, and of course, that broke the chain (but that is a different issue).

Here's a very simple one, and so far it seems to be working just fine.

ruleset test_554 {
  rule keep_it_moving {
    select when test_554 tick_tock
    fired {
      schedule test_554 event "tick_tock" at time:add(time:now(),{"minutes":1})
        setting(schedule_id);
      ent:schedule_id := schedule_id;
    }
  }
  rule do_something {
    select when test_554 tick_tock
  }
  rule stop_it {
    select when test_554 idle_request
    if ent:schedule_id then schedule:remove(ent:schedule_id);
    fired {
      clear ent:schedule_id;
    }
  }
}