Support editing existing schedules in the Web UI while preserving execution history

[golitter]

Background

The Web UI currently supports creating schedules with an activation window (started_at / ended_at), but provides no way to edit them afterward.

To adjust the start time, extend or remove the end time, or change the execution frequency, users have to delete the schedule and create a new one. However, deleting a schedule also deletes its associated execution sessions, resulting in the loss of execution history.

Proposal

Add an edit action to the schedule details view, allowing users to update existing schedule settings, including:

• Activation start and end times, with the option to remove the end time.
• Execution frequency and trigger time.
• Existing updatable fields such as name, description, and enabled status.

Saving changes should update and reschedule the existing task while preserving its ID and all execution history. Editing should retain the schedule’s stored timezone without introducing a timezone selector.

Current API limitations

The backend already provides PATCH /schedule/{id}, but it does not support started_at / ended_at. The frontend also has an update API wrapper and hook, but the UI does not expose an editing action.

Additionally, PATCH currently silently ignores activation window fields and returns 200. For example, submitting a new ended_at still returns the old value. This can mislead callers into believing the update succeeded and should be addressed when adding support for these fields.

Scope and update semantics

This proposal focuses on Web UI editing and the backend support it requires. Adding an agent update tool, introducing timezone selection, and changing unknown-field handling across all request models are outside its scope.

For activation window updates, the proposed semantics are:

• Omitted fields: retain their current values.
• ended_at: null: remove the end boundary.
• Updating a single boundary: validate it against the existing value of the other boundary.
• Invalid windows: return a clear error and leave the existing schedule configuration unchanged.

If this direction makes sense, I think I could try implementing this functionality.