drupflare/worker - v1.0.0
    Preparing search index...

    Function cronStep

    • Does ONE unit of cron work and hands back the next cursor.

      Shaped as a pure-ish function of (cursor, deps) so the caller keeps ownership of persistence: the cursor goes to cfw_meta or ctx.storage.put(), whichever the Durable Object already uses, and neither choice leaks in here. That is also what makes the chain testable without a Durable Object at all.

      mayContinue is the CPU constraint expressed as data. A sql unit costs microseconds, so the caller may run another in the same invocation; a php unit enters the interpreter and must be the last thing that invocation does. This is the same trade fillBatchSize()/fillBatchWallMs() make in src/site-do.js -- batch to amortise the setAlarm() row write, but never batch across a render.

      result is the unit's own ledger or reply and its shape depends on the unit, so it is declared as an index signature rather than object -- a bare object makes every field unreadable to a typed caller, which is what the ported specs hit.

      Parameters

      • rawCursor: CursorInput

        whatever storage returned. undefined is a real input, not a defensive allowance: an evicted Durable Object comes back with nothing, and that case is tested

      • deps: CronDeps

        the transport and clock, injected so the chain owns neither

      • options: CronOptions = {}

        passed through to cronUnits() and the GC passes

      Returns Promise<CronStep>