Skip to content

Schedules: add atomic reschedule and reactivation semantics #2149

Open

Description

@kantord

Outcome

Users can intentionally reschedule or reactivate an existing schedule without replacing its identity, losing history, or leaving firing state inconsistent with its edited trigger and limits.

Product intent

The Mecatl design-reference prototype keeps Edit available for every schedule, including rows whose run limit is reached. Its edit flow exposes cadence, one-shot time, retry policy, and maximum runs. The detail page explicitly labels an exhausted schedule as “limit reached” while retaining Edit.

The production backend does not currently satisfy that intent:

  • Studio must reject trigger changes because ordinary update preserves the old nextFireAt.
  • Raising maxFires on an exhausted schedule does not re-enable it or compute a new next fire.
  • Lowering limits can stop eligibility without reconciling displayed firing state.
  • A successfully completed one-shot is not re-armed by changing retry settings.

#1852 will lock controls whose changes cannot take effect safely.

Scope

  • Define explicit reschedule/reactivate semantics separately from ordinary metadata update.
  • Recompute next-fire state atomically from the new trigger and timezone.
  • Define behavior for paused, completed, exhausted, claimed, and currently running schedules.
  • Preserve stable identity, ownership, placement, counters, and fire history unless the operation explicitly resets a documented field.
  • Define optimistic-concurrency/collision behavior so stale editors cannot overwrite newer scheduling state.
  • Expose capability and refusal reasons through the SDK and Studio BFF.

Acceptance

  • A successful cadence change cannot retain the old next-fire instant.
  • Increasing a run limit can reactivate exhausted recurring work only through the explicit operation.
  • Completed one-shots are never rerun accidentally.
  • Claimed or running work follows a documented old-spec/new-spec boundary.
  • Partial failure cannot leave spec and scheduler state disagreeing.

Parent: #1736
Discovered while designing: #1852
Design reference: /home/kantord/repos/mecatl-prototypes, schedule list/detail/edit flows on the stack/05-schedules design branch.

Activity

  1. jbeda commented on Oct 18, 2026

    @jbeda
    Contributor

    Deferred mecatui follow-up from #2398: edit an existing schedule without replacing its identity or losing history. The basic creator deliberately omits editing. Please include the terminal editor as a consumer of this issue's safe update/reschedule/reactivation contract: preserve untouched policy and lifecycle state, retain drafts on failure, distinguish metadata edits from rearming, and cover stale editors plus claimed/running/completed schedules. #2146 owns the narrower post-one-shot mutable-field case; #2147 owns tool-profile changes. This adds no editing behavior to #2398.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions