Reservations can become due while an application is closed or a computer sleeps. Launching every old action on return risks late delivery and duplication. I separate missed timing from interrupted execution and inspect retained state before deciding on another operation. Restart itself is not renewed permission to act.
First identify lateness before execution began
General project jobs retain a missed state instead of dispatching queued work more than two minutes late. The Cafe queue uses a failed state with a missed-time reason for its corresponding boundary. Names differ while the policy against unconditional catch-up remains recognizable.
Two minutes is the current implementation's threshold, not a universal rule for every business operation. The essential behavior is refusing to quietly execute or rewrite the time after exceeding it. The operator needs a visible reason and a deliberate decision about a new schedule; late execution cannot be reported as having happened on time.
Folder-worker lateness has its own state
The folder worker also retains an overdue start, and its first-item boundary can stop an overdue beginning as unconfirmed. It is a different executor from the general reservation queue, with different state fields that should not be described as one identical implementation.
This does not move the content's visibility time forward and create a new schedule. Publication timing and worker start are already separate data. Diagnosis needs to identify which time passed and which operation never began. One generic reservation-failed label cannot determine the cause or the next action accurately.
Do not turn retained running state into fresh queued work
On restart, general and Cafe running records become review-needed. Losing the process does not establish that no external action was delivered. A retained run identity and files should lead to inspection of the original result, not bypass through a newly invented identity.
The existing unit scenario reopens a running record and requires zero dispatch calls. It does not reproduce every possible power interruption. This writing neither sleeps the user's computer nor closes the original app. Restoration code and the conditions covered by existing tests retain their distinct evidence.
Permitted reconciliation is different from resubmission
The Cafe queue has a constrained reconciliation route requiring a known run identity, suitable error and version-specific eligibility. The application selects a verify-published operation there. It does not publish every review-needed item again. Another observation and another submission are different actions.
The folder publisher likewise queries a retained run without repeating page preparation or file selection. An intent record with no run identity does not authorize automatic redelivery. Accurate recovery instructions identify which reads are permitted and which mutations remain blocked rather than describing all post-interruption automation as the same retry.
Resume checks paused state and a future time again
Resume requires the correct owner scope, paused state and a future intended time. It is not a universal recovery button converting missed or uncertain records back into queued. Retained outcomes, material and current time need inspection before deciding on a genuinely new request.
An interrupted local registration also needs its actual state checked. The bridge reports interruption and directs inspection of registration rather than assuming another register call is safe. Requesting registration, reading a retained registration and completing the external business operation remain separate stages.
Retain an explainable record instead of hidden late execution
People leave work unattended because they trust a reservation. A visible account of what was missed and what already progressed is more useful than quietly performing it late. Conditions that prevented timely execution are part of the result, even when a success counter would conceal them.
Scheduled billing, notifications and document delivery have the same concern. Whether lateness is acceptable and whether present intent remains need deliberate decisions. Designing reservations includes preserving the operator's choices after time passes, not merely adding a timer that eventually fires.