Run the Laravel scheduler in production (start.sh) #19

New issue

Open

opened 2026-04-26 01:26:44 +02:00 by myrmidex · 0 comments

myrmidex commented

2026-04-26 01:26:44 +02:00

Owner

Context

routes/console.php registers Schedule::command('fedi-discover:poll')->everyMinute()->withoutOverlapping(5)->runInBackground(). This only fires if Laravel's scheduler is actually running.

The prod container's start.sh (per .claude/PLATFORM.md) currently does: wait for PG → package:discover → config:cache → route:cache → view:cache → migrate --force → FrankenPHP. There is no schedule:work (or cron entry calling schedule:run) in the start script.

Result: the v0.1 fedi-poller is registered but never fires in production. Ticket #3 ships dead code in production until this is fixed.

Goal

The Laravel scheduler runs as a long-lived process alongside FrankenPHP in the production container, so registered scheduled tasks (like fedi-discover:poll) actually fire.

Options

schedule:work as a separate process — long-lived, internally tick-loops every minute. Either:
- Use a process supervisor (e.g. supervisord, s6-overlay) inside the container to run both FrankenPHP and schedule:work.
- Or use FrankenPHP's worker mode + a dedicated container side-process.
External cron — runs php artisan schedule:run every minute from outside the container. Adds an external dependency.

Option 1 is more self-contained for a single-container deploy. Option 2 is more portable but requires cron infrastructure.

Pick whichever fits the deployment model.

Acceptance criteria

docker/prod/start.sh (or equivalent) launches the scheduler process at container boot.
Process supervisor or background process pattern that survives FrankenPHP exits without orphaning.
Verifiable: in a deployed container, fedi-discover:poll runs every minute (check last_polled_at advancing on enabled instances).
Documentation: PLATFORM.md and README updated to reflect the dual-process model.

Severity

High — blocks ticket #3's value in production. Without this, every-minute polling is a no-op.

## Context `routes/console.php` registers `Schedule::command('fedi-discover:poll')->everyMinute()->withoutOverlapping(5)->runInBackground()`. This only fires if Laravel's scheduler is actually running. The prod container's `start.sh` (per `.claude/PLATFORM.md`) currently does: wait for PG → `package:discover` → `config:cache` → `route:cache` → `view:cache` → `migrate --force` → FrankenPHP. **There is no `schedule:work` (or cron entry calling `schedule:run`) in the start script.** Result: the v0.1 fedi-poller is registered but never fires in production. **Ticket #3 ships dead code in production until this is fixed.** ## Goal The Laravel scheduler runs as a long-lived process alongside FrankenPHP in the production container, so registered scheduled tasks (like `fedi-discover:poll`) actually fire. ## Options 1. **`schedule:work` as a separate process** — long-lived, internally tick-loops every minute. Either: - Use a process supervisor (e.g. supervisord, s6-overlay) inside the container to run both FrankenPHP and `schedule:work`. - Or use FrankenPHP's worker mode + a dedicated container side-process. 2. **External cron** — runs `php artisan schedule:run` every minute from outside the container. Adds an external dependency. Option 1 is more self-contained for a single-container deploy. Option 2 is more portable but requires cron infrastructure. Pick whichever fits the deployment model. ## Acceptance criteria - `docker/prod/start.sh` (or equivalent) launches the scheduler process at container boot. - Process supervisor or background process pattern that survives FrankenPHP exits without orphaning. - Verifiable: in a deployed container, `fedi-discover:poll` runs every minute (check `last_polled_at` advancing on enabled instances). - Documentation: PLATFORM.md and README updated to reflect the dual-process model. ## Severity **High** — blocks ticket #3's value in production. Without this, every-minute polling is a no-op.