Extracted for the same reason cronAlarmDelayMs and updbAlarmDelayMs exist: this is a
three-branch decision that lived inline in alarm() as a ternary, and it was the only one of
the three alarm chains with no unit test.
That is how a real bug survived in it. The ternary read pending.done, but the caller hands it
{ migrate: out }, so done was ALWAYS undefined: the idle branch was unreachable, and the
firing that COMPLETED a migration re-armed at 1 ms instead of 240 s. Cheap in practice, because
the next firing finds the cursor done, returns null and falls through to the fill loop -- but
the branch was dead and the intent defeated. Taking the step result DIRECTLY rather than the
wrapper is what makes that mistake unspellable here.
Parameters
Optionalout: {done?:boolean;ok?:boolean}|null
a migrator step result, or the { ok: false } shape the catch path returns
How long to wait before the next migration alarm.
Extracted for the same reason
cronAlarmDelayMsandupdbAlarmDelayMsexist: this is a three-branch decision that lived inline inalarm()as a ternary, and it was the only one of the three alarm chains with no unit test.That is how a real bug survived in it. The ternary read
pending.done, but the caller hands it{ migrate: out }, sodonewas ALWAYS undefined: the idle branch was unreachable, and the firing that COMPLETED a migration re-armed at 1 ms instead of 240 s. Cheap in practice, because the next firing finds the cursordone, returns null and falls through to the fill loop -- but the branch was dead and the intent defeated. Taking the step result DIRECTLY rather than the wrapper is what makes that mistake unspellable here.