Skip to content

Allow fresh 2.x installs without legacy 1.x tables or drain overhead #513

Description

@rmcdaniel

Independently verified problem

WorkflowServiceProvider::boot() unconditionally loads src/migrations, including all six 2022_01_01_* migrations. A fresh 2.x install therefore creates workflows, workflow_logs, workflow_signals, workflow_timers, workflow_exceptions, and workflow_relationships, even if the application only uses v2.

The queue Looping listener also always calls the legacy Watchdog::wake(). The watchdog checks whether the legacy table exists, but the default fresh migration creates it.

This is avoidable installation/operation overhead, not evidence of a failed v2 workflow or a data-integrity defect. Retained v1 code supports existing applications draining old work; deleting it indiscriminately would break that adoption path.

Intended outcome

Provide an explicit, documented v2-only installation path, and review whether fresh installs can select it automatically without changing existing applications' behavior. Keep legacy migration/drain support available for real 1.x upgrades. Do not automatically drop any existing tables or history.

Acceptance

  • Fresh v2-only migrations create the required v2 schema without the six legacy tables.
  • v2-only queue execution does not poll/schedule legacy watchdog work.
  • Existing 1.x installations can still drain old workflows while starting v2 work; reopening an existing application must not silently disable recovery.
  • Published migrations, migration ledger identity, rollback behavior, custom storage connections, and cached configuration have focused regression coverage.
  • Waterline embedded installation and Server consumption are checked against the chosen mode.
  • Document the upgrade-safe switch and publish a semver-appropriate release with a clean-install check against published artifacts.

Priority

Accepted product cleanup, after active reliability/recovery work and already accepted user-reported defects. Do not turn this into removal of supported upgrade functionality or a prerequisite for unrelated Cloud recovery qualification.

Activity

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

    priority:P2Normal-priority product work

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions