IssueTracker

I'm not sure I understand how workRequestBuilder.setInitialDelay() is meant to work in respect of a Periodic Work Request (which is possible as from 2.1.0).  Maybe what I'm seeing is a bug, or maybe it's intended behaviour.  If the latter, it seems like odd intended behaviour.

When I set up a periodic job, I want the first in the series to be performed INSTANTLY (the user expects it... they hit a button and are waiting for an immediate result), and then for subsequent ones to be performed based on the periodic schedule (more vague timings is fine... the user is no longer waiting).

When you set up a periodic work request *without* a flex interval, it can run anytime in the set interval, i.e. from NOW until the end of the interval.  If the device is awake when the periodic work request is scheduled, which is the case for me, I find that the first work in the series is generally performed at the START of the interval, i.e. NOW... though "NOW" may not be instantly (it's up to the device to decide... may be delayed a few seconds).

Because it cannot be guaranteed that the first periodic work will be performed *instantly*, instead I do an explicit call to the work-performing function outside of the WorkManager realm, and put a flexInterval on the periodic work of 5 mins so that the first periodic work will certainly not be performed straight away, but instead it will be near the end of the first period, most likely 5 mins before the end.  This is not quite ideal (first gap between work runs is not quite a full interval) but it's OK... the user won't care or even notice it runs 5 mins "early" the first time.

Now, I thought that the ability to set an "initialDelay" in 2.1.0 would solve my problems... so that I could:

(a) still make an explicit call to the work-performing function to do the immediate work, guaranteed to be NOW (the user expects that)
(b) set up a periodic work request WITHOUT flexInterval (i.e. use the whole interval) and WITH an initial delay equal to the period "interval"

That way, I get the immediate work done, and then after "interval" the periodic work request is scheduled, and because (let's assume) the device is still awake, the first periodic work will likely perform at the START of the interval, i.e. almost straight away, i.e. pretty close to exactly one "interval" after the user set the schedule going.

BUT I'm not finding that.  Let's say that "interval" of the periodic work is 15 mins, and I set an "initial delay" also of 15 mins, and I set this going when the user hits the button.  I find that the immediate work is performed at 0 mins (triggered explicitly, not by WorkManager, so that's as expected), then at 15 mins NOTHING happens, and only at 30 mins does the first periodic work actually run.

It seems that either the first periodic work happens at the END of the first interval (15-30 mins) and not the start (like it usually does, if the device is awake and not busy), or WorkManager delayed first periodic interval to be at 30-45 mins, i.e. it waited 30 mins not 15 mins, twice what I asked for.

So, how is "setInitialDelay" for a periodic work request meant to work?  It doesn't just wait "delay" (instead of not waiting at all) and then enqueue the periodic work request?