Skip to content

refactor: remove the process-schedule remnant from the scheduler (tables created at boot, polled every sync, execute path posts to a route that no longer exists) #3432

Open

Description

@vybe

Summary

The process engine was removed from the backend, but the scheduler still carries its scheduling half: it creates two tables at boot, re-reads them on every sync cycle, and holds an execute path that posts to a backend route that no longer exists. Nothing in the tree can create a row, so the code is dead by construction and still costs a query per sync cycle on every instance.

Context

Static review of dev at f6bedcd8. Sibling of #2491 (the non-scheduler process-engine remnants) and #2494 (memory-doc drift); kept separate because #2491 is deletions of unreachable files, while this removes branches from live scheduler code paths.

Why it is dead, not merely unused:

  • process_schedule appears in exactly two production files, both under src/scheduler/ (service.py, database.py). The backend has no router, service, db module or table definition for it.
  • The execute path posts to /api/processes/{id}/execute (src/scheduler/service.py). No such route exists.
  • create_process_schedule, add_process_schedule, remove_process_schedule and update_process_schedule have no caller anywhere in src/.
  • The two tables are created ad hoc by ensure_process_schedules_table. They are not in db/schema.py, db/tables.py or any Alembic revision, which the schema invariant forbids.
  • Four process_schedule_execution_* WebSocket event types are published only from this path; no frontend listener references them.

Acceptance Criteria

  • The scheduler no longer creates, loads, syncs or executes process schedules; git grep -n process_schedule src/ is empty
  • ProcessSchedule and ProcessScheduleExecution are gone from src/scheduler/models.py
  • The lock-denial and skipped-run helpers shared with agent schedules (bug: cron tick suppressed by distributed lock leaves no execution record #1969, bug(scheduler): _execute_process_schedule lock-denial branch still unaudited (sibling of #1969) #1994) keep working for agent schedules; only the process branch is removed
  • tests/unit/test_1994_process_schedule_lock_audit.py is removed; the process cases in tests/scheduler_tests/ (test_skipped_executions.py, test_1474_timestamp_z_suffix.py, test_sync_loop.py) are cut and the agent-schedule cases still pass
  • tests/run-core.sh no longer passes --ignore=process_engine (the directory is not in the tree)
  • docs/memory/feature-flows/scheduler-service.md, docs/memory/requirements/scheduling.md and docs/memory/architecture/execution.md no longer describe process schedules as a working part of the scheduler (archive and release docs stay as they are)
  • An instance that already has the two empty tables boots and schedules normally after the change
  • Scheduler and unit suites green

Technical Notes

  • Open choice for the implementer: drop the two empty tables (needs a migration on both the SQLite and Alembic tracks) or leave them. Leaving them is harmless once nothing reads them; say which was chosen in the PR.
  • This touches the scheduler's sync loop and reload path, so sequence it after the 1.0 release is cut, not during release testing.

Activity

  1. added
    complexity-mediumComplexity: medium (board points 5-8)
    status-readyGreenlit and ready for development (vetted; counterpart to status-incubating)
    on Oct 9, 2026
  2. vybe commented on Oct 9, 2026

    @vybe
    ContributorAuthor

    Draft PR: #3440 — reviewed MERGEABLE, scheduler tier 241 passed / 0 failed, merge-tree clean against dev. Tables are left in place (no migration). Before merge: land after the 1.0 release is cut and before the dead-symbols PR for #3433; confirm the legacy-tables boot on one PostgreSQL instance (proven on SQLite only).

  3. removed
    status-readyGreenlit and ready for development (vetted; counterpart to status-incubating)
    on Oct 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions