Laravel Aws Worker Laravel Package

Getting Started

1. Confirm the package's v2 Composer constraints against your Laravel/PHP version before upgrading. v2 is a major release specifically because scheduler behavior and older Laravel compatibility may change.
2. Review the package diff around the /worker/schedule route/controller and compare it with php artisan schedule:run behavior in your app.
3. Upgrade in a non-production branch with composer require <package>:^2.0, then run php artisan route:list and confirm /worker/schedule is still registered and protected as expected.
4. Verify native scheduling works first: php artisan schedule:list and php artisan schedule:run -v. The package endpoint should now be a thin delegation layer over this behavior.
5. First use case: use /worker/schedule as an HTTP/cron trigger for Laravel's scheduler when you cannot run traditional system cron—e.g. PaaS, containers, serverless, or an external uptime service.

Look first at the package README/upgrade notes, the /worker/schedule route definition, any scheduler-related config, and your app's routes/console.php or console kernel schedule definitions.

Implementation Patterns

• Define scheduled tasks using Laravel's native scheduler APIs as usual; v2 delegates to schedule:run, so package-specific scheduling semantics should not be assumed.
• Use the endpoint as an external trigger that calls the native scheduler. Configure your external cron/uptime monitor to hit it at the cadence you would normally run php artisan schedule:run—typically every minute.
• Protect the endpoint with middleware, a secret header, signed URLs, IP allowlisting, or equivalent. It can trigger scheduled commands and should not be publicly callable.
• Rely on native Laravel scheduling features such as withoutOverlapping(), onOneServer(), runInBackground(), timezone settings, and environment filters rather than package-specific alternatives.
• For integration tests, freeze time with Carbon::setTestNow() so tasks are due, then feature-test the endpoint and assert command output, side effects, or dispatched jobs.
• When migrating from v1, compare v1 behavior against native schedule:run in staging. Check task locking, output capture, exit codes, maintenance-mode behavior, timezone handling, and environment filters.
• If v1 exposed custom scheduler behavior that your app depends on, stay on ^1.0 until you have verified parity or refactored to native scheduler behavior.
• For long-running scheduled tasks, prefer queued/background execution. An HTTP-triggered scheduler can hit web server, PHP, or proxy timeouts.

Gotchas and Tips

• This is a breaking change: /worker/schedule now delegates to Laravel's native schedule:run. Behavior can differ from v1 in output, exit codes, task filtering, locking, and error handling.
• Older Laravel compatibility may be affected. Check Composer constraints before upgrading; if you are pinned to an older Laravel version, remain on ^1.0.
• Avoid multiple concurrent callers hitting /worker/schedule; native schedule:run will still run due tasks. Use withoutOverlapping() and onOneServer() where appropriate to prevent duplicate execution.
• Debug by comparing endpoint behavior with local php artisan schedule:list and php artisan schedule:run -v. If the endpoint response no longer exposes the same detail as v1, inspect application logs and scheduler events.
• Watch for environment quirks: APP_ENV, maintenance mode, timezone configuration, and per-environment schedule definitions can cause tasks to be skipped or run at unexpected times.
• Prefer Laravel's scheduler events—such as ScheduledTaskStarting, ScheduledTaskFinished, and ScheduledTaskFailed—for observability instead of relying on package-specific hooks.
• If you depend on v1's previous scheduler behavior, pin to ^1.0 and plan a deliberate migration rather than treating v2 as a drop-in upgrade.