Durable work should wait until it is due

A repository should wake promptly when a person resumes work, then become quiet when only future retries remain. T-300 repairs three scheduling interactions in Nerudo's existing per-repository Durable Object: indexing retry backoff, exact-page showcase scans and urgent landing wake-ups. It keeps the existing coordinator and permission boundaries.

These figures are original browser captures of scripted local executions of the actual compiled Rust Worker in workerd and SQLite. A labelled inspection adapter displays original native timer and endpoint response fields. Synthetic state, explicit alarm steps and injected errors are identified; no production bill reduction or recorded coding-provider outcome is claimed.

A retry deadline survives other wakes

The indexer previously armed its next 25 ms continuation while recording work, before it knew whether the current step would succeed. If the step failed, the error handler found an alarm already scheduled and left it there. Its log could promise a two-second or one-minute backoff while the next wake remained almost immediate.

The running indexer now records demand separately from scheduling its continuation. On failure it retains a repository-local retry timestamp. An earlier alarm can still wake the repository for landing or history work, but the index checks the durable timestamp and performs no index SQL before it is due. A cold isolate reads the same deadline. Once it expires, the original work can run again.

The scripted execution also fails the deadline write itself. The error stays visible and the in-memory busy guard is released, allowing the following alarm to resume work. This preserves recoverability rather than silently acknowledging a failed persistence operation.

After the injected indexing failure, the scripted Worker requested 2000 ms with one prior failure and 60000 ms with six; after cold restart, an earlier wake performed zero indexing SQL statements and preserved its earlier timer.

The last full page is still the end

A scan consumed 32 records per page and treated a count of 32 as proof that more records existed. With exactly 32 or 64 future jobs, it reached an empty page, reset its cursor, and immediately began the same scan again. No job needed to run, yet the object kept asking for 25 ms alarms.

The scanner now reads one lookahead record. Only a real next record establishes another page, and the cursor advances through consumed records rather than the lookahead. At the true end it returns to a future wait; an unchanged cursor needs no rewrite.

The figure includes the boundaries around a page and two pages. A separate execution restarts workerd between pages, then reaches a deliberately due record on page 3. That synthetic task is intentionally absent: its stored attempt count and new retry deadline establish that the due record was reached and retained, not that a provider completed the job.

With exactly 32 future jobs, the scripted alarm requests changed from repeated 25 ms wakes to 60000 ms waits; with 64 jobs, each complete two-page scan also reached a future wait, and a due record on page 3 was reached after restart.

Explicit actions can advance a later timer

The shared ensure-alarm helper only created an alarm when none existed. That is useful for background continuations that should preserve an established retry, but it left a successful resume or a newly accepted submission waiting behind an unrelated later timer.

Explicit landing actions now request an urgent wake through an earliest-deadline helper. It advances a later alarm to the immediate wake window, while preserving an alarm that is already earlier. Resume, submission and approval or allowance wake-ups still pass their existing authority and persistence checks. Scheduling cannot approve a change or bypass CI.

The captured endpoints accept resume and queue a submission with a timer previously nearly five minutes away. Another captured response retains a sooner native deadline without an extra alarm write. The test also checks that those urgent actions leave the durable indexing cooldown unchanged. That distinction lets landing work wake promptly without restarting a failed background index too soon.

The scripted resume and new-submission endpoints both returned HTTP 200 and requested a 25 ms wake instead of retaining a timer nearly five minutes away; the submission remained queued, and an already earlier alarm was preserved with zero extra alarm writes.

The correction adds an optional retry timestamp in the existing repository store and needs no namespace or SQL-schema migration. An older Worker ignores it on rollback and restores the prior scheduling behavior. Controlled before/after records, source/build hashes and reproduction commands are retained in the landed product evidence. Owner architecture and visual review and normal human release signing remain independent.