fix(tasks): preserve schedules during startup initialization

[zZebrahz]

Related issue: #999

Startup could overwrite an administrator's schedule edit made while defaults were being resolved. A failed schedule read or write could also activate defaults that were never saved. Current main already retains empty schedules through API v2 schedule revisions; this change completes the startup behavior using that same repository.

Initialize defaults with the existing revision-zero guard. If an administrator has saved a schedule, load it without changing its revision. Consult default providers only for unsaved schedules, and keep automatic runs idle after a storage error. The branch now incorporates current main and requires no additional migration or API shape changes.

Validation:

• Manager persistence tests passed with the race detector. Concurrent-edit and storage-failure regressions fail on current main and pass with this change.
• All taskmanager packages passed. Repository tests passed with the race detector against disposable PostgreSQL 17, covering empty schedules, rollback, concurrent initialization/edits, and preservation of API v2 revisions.
• Go build, vet, changed-line lint, formatting, contract/fixture gates, migration validation, and local-path checks passed. The local-path script ran under Bash 5 after the system Bash crashed.
• Web dependency installation, lint, formatting, production build, and all 598 test files / 4,600 tests passed.
• The full Go run failed in unchanged code: the macOS resource-capability test and policy evaluation deadlines. The policy tests passed on a focused retry. Two existing taskmanager test-helper races also reproduce on the original base. No required failures were hidden or added to exclusion lists.

Automatic scheduling after a storage failure recovers when an administrator saves the schedule or the server restarts after storage recovers. Other running processes still reload schedules on restart. Autoscan settings saves still replace its poll schedule. No Apple, Android, or Jellyfin changes are needed.

The original implementation was tested by the maintainer. This integration update has automated validation; it has not received a new manual deployment test.

AI disclosure:

• Harness: OpenAI Codex app
• Model: gpt-6-astra
• Tools: Codex tools (functions.exec, exec_command, apply_patch), GitHub CLI, Docker, repository unslop skill, Modern Go Guidelines CLI
• Involvement: AI-generated implementation and integration update; original implementation human verified
• Adversarial review: traced startup, persistence, rollback, concurrency, and API v2 schedule ownership. Reproduced the remaining startup regressions and replaced the overlapping marker-table design with the existing revision guard. No independent reviewer was used.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-22T16:18:24.609136Z	0fd3722	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: c6498339-35a7-4a3c-8dad-7926243fa679

📥 Commits

Reviewing files that changed from the base of the PR and between 25e460f and 188a57f.

📒 Files selected for processing (8)

• docs/admin-api.md
• internal/taskmanager/manager.go
• internal/taskmanager/manager_persistence_test.go
• internal/taskmanager/manager_test.go
• internal/taskmanager/repository/postgres_triggers.go
• internal/taskmanager/repository/postgres_triggers_test.go
• internal/taskmanager/triggers_repo.go
• migrations/sql/20260906235758_preserve_empty_task_schedules.sql

Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.

---

📝 Walkthrough

Walkthrough

Task schedules now distinguish missing configurations from saved configurations, including explicit empty schedules. PostgreSQL persists schedule initialization state, startup resolves defaults atomically, and failures keep automatic runs idle.

Changes

Task schedule persistence

Layer / File(s)	Summary
Schedule contract and persistence marker internal/taskmanager/triggers_repo.go, migrations/sql/*preserve_empty_task_schedules.sql	The repository contract reports whether a schedule exists. The migration adds task_trigger_sets and backfills legacy task keys.
Transactional PostgreSQL schedule handling internal/taskmanager/repository/postgres_triggers.go, internal/taskmanager/repository/postgres_triggers_test.go	The repository locks schedule sets, seeds defaults only for new sets, preserves empty schedules and legacy rows, and rolls back failed writes.
Startup schedule resolution internal/taskmanager/manager.go, internal/taskmanager/manager_test.go, internal/taskmanager/manager_persistence_test.go	Startup loads saved schedules, seeds defaults only when no schedule exists, and keeps automatic runs idle after load or seed failures.
Schedule behavior documentation docs/admin-api.md	The admin API documentation describes replacement semantics, empty schedules, startup failures, migration behavior, and Autoscan updates.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant TaskManager
  participant TriggerRepository
  participant PostgreSQL
  TaskManager->>TriggerRepository: Load or create task schedule
  TriggerRepository->>PostgreSQL: Lock schedule set and read triggers
  PostgreSQL-->>TriggerRepository: Saved schedule or missing schedule
  TriggerRepository->>PostgreSQL: Persist defaults when missing
  TriggerRepository-->>TaskManager: Return resolved schedule

Loading

Suggested reviewers: quick104

Merge Risk: ⚪ Minimal · up to 188a5

Schedule initialization and explicit empty schedules are preserved across restarts, with automatic runs remaining idle when storage fails. No unresolved merge-blocking risk remains.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 13.33% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 15 functions across 6 files. (2 skipped: …	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: preserving task schedules during startup initialization.

Full details: Docstring Coverage

Explanation

Docstring coverage is 13.33% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 15 functions across 6 files. (2 skipped: 2 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/preserve-task-schedules

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Quick104]

The submitted persistence behavior passed focused manager tests and PostgreSQL race tests. There is one integration issue with current main, described below; I am updating this branch to address it. The broader taskmanager race run also exposes two test-helper races that reproduce on the original base, so they are not findings against this PR.

AI disclosure: review by gpt-6-astra in the OpenAI Codex app, using Codex tools, GitHub CLI, and the repository unslop skill.

[Quick104]

Fixed and pushed the schedule integration concern in 0fd372212c4673da7a89a49b862612a08a9680fb.

Startup now uses API v2's existing schedule revisions to initialize defaults, preserves an administrator edit made during default resolution, and leaves automatic runs idle after storage failures. The redundant migration is removed. The branch incorporates main, and the admin documentation describes the current API v2 behavior.

Validation passed: build, vet, changed-line lint, manager persistence regressions, all taskmanager packages, PostgreSQL repository race tests, contract/fixture gates, migration validation, formatting, and web build/lint plus 598 test files / 4,600 tests. The startup regressions fail on main and pass with the repair. Full local Go testing encountered an unchanged macOS resource-capability failure reproduced on main and policy deadlines that passed on focused retry. Two existing taskmanager test-helper races also reproduce on the original base. Local-path checks passed under Bash 5 after the system Bash crashed.

No actionable review findings remain. Project fit is sound: startup and administrator edits share one durable schedule owner and the same concurrency guard. No API shape or Apple, Android, or Jellyfin changes are needed.

CI on the reviewed head is still running. Passing that run is the remaining merge condition; the prior head's green checks do not validate this update.

AI disclosure: gpt-6-astra in OpenAI Codex, using Codex tools, GitHub CLI, Docker, repository unslop, and Modern Go Guidelines. Same-agent adversarial review; no independent reviewer.

Mergeability: 8/10 — conditional, reviewed head 0fd372212c4673da7a89a49b862612a08a9680fb: the integration concern is addressed and relevant local validation passed; fresh CI remains pending.