Scheduler Laravel Package

Getting Started

Read this first: netflex/scheduler is a read-only subtree split of netflex/framework. Do not treat it as an independent package — the canonical source of truth, issues, and pull requests live in the netflex/framework monorepo. The split exists so Composer can resolve individual components, but you should almost never composer require netflex/scheduler on its own.

Minimal steps:

1. Install the framework, not the component:

   composer require netflex/framework
   

   Pulling netflex/scheduler alone will leave you missing the framework contracts, service providers, and bootstrapping it expects to hook into.

2. Confirm what you actually got — the split packages are pinned to the framework version:

   composer show netflex/scheduler
   composer show netflex/framework
   

   The two versions should track each other. If they don't, you have a resolution problem.

3. Locate the source:

   ls vendor/netflex/scheduler/src
   

   Read the service provider (usually SchedulerServiceProvider or similarly named) and the composer.json require / autoload blocks first. Those two files tell you the extension points and the Laravel version constraints before you read any scheduling logic.

4. First use case: In a Netflex/Laravel app, this component is the layer that registers scheduled tasks with the framework's console kernel. Start by verifying your existing Kernel::schedule() (or the Netflex equivalent) still runs after install:

   php artisan schedule:list
   php artisan schedule:run -v
   

   If your existing schedule entries still appear, the component has wired itself in correctly and you can build on top of it.

Reality check: With 0 stars and 0 dependents, there is effectively no community documentation, no Stack Overflow corpus, and no third-party tutorials. Treat the vendor source as the documentation. Budget an hour to read src/ end to end — it will be small.

Implementation Patterns

Because this is a component of a closed ecosystem, the patterns below are the ones that matter in practice. Verify exact class names against your installed version — they are stable within a minor, but the split gives you no changelog.

Pattern 1 — Register through the framework, not the component. The correct integration point is the application's console kernel, which the framework bootstraps. Add your scheduled work there, not by instantiating scheduler classes directly:

// app/Console/Kernel.php
protected function schedule(Schedule $schedule): void
{
    $schedule->command('netflex:sync')->hourly();
    $schedule->job(new ReindexContentJob)->dailyAt('02:00');
}

If the Netflex scheduler exposes its own fluent registration API, prefer it — it likely carries tenant/site context that raw $schedule calls do not.

Pattern 2 — Treat it as the "when", Laravel as the "what". Use the component for registration and dispatch; use Laravel's Schedule methods (->hourly(), ->withoutOverlapping(), ->onOneServer()) for cadence and safety. This keeps your code portable if you ever leave the Netflex ecosystem.

Pattern 3 — Wrap scheduled work in queued jobs. Any scheduled task doing more than trivial work should dispatch a job, not run inline. The scheduler fires, the queue does the work, and a slow task can't block the next tick:

$schedule->job(new SyncCatalogJob($siteId))->everyFifteenMinutes();

Pattern 4 — Multi-tenant awareness. Netflex is a CMS platform; scheduled tasks usually need a site/tenant scope. Expect to iterate sites and register per-site entries, or dispatch a job per site from a single entry. Check whether the component has a site-aware registration helper before you hand-roll the loop.

Pattern 5 — Hook your observability in once. Register global before/after/onFailure callbacks on the schedule rather than repeating them per task. This is the cheapest place to add structured logging and metrics, and it survives new task additions.

Integration tip: If you need behavior the component doesn't expose, do not patch vendor/netflex/scheduler. Extend it in your app's service provider, or fork the monorepo. The subtree split is regenerated on every framework release and your edits will vanish on composer update.

Gotchas and Tips

The biggest gotcha: editing the split. Files under vendor/netflex/scheduler are overwritten whenever netflex/framework releases. The repository README literally says [READ ONLY]. Any fix or feature must go to the monorepo. Plan for that friction before you build a workaround on top of modified vendor code.

Version drift between split and monorepo. Subtree splits are generated at release time. If you see behavior that doesn't match the netflex/framework tag you think you're on, check whether the split was regenerated for that tag. Pin both packages to explicit versions in composer.json rather than floating constraints, at least until you trust the release pipeline.

Debugging scheduled tasks. The usual Laravel tools apply, but lean on them harder here because there's no documentation:

php artisan schedule:list          # what's registered
php artisan schedule:run -v        # what actually fires
php artisan schedule:test          # isolate a single task (Laravel 8+)

If a task silently doesn't run, check in this order: (1) it appears in schedule:list; (2) the cron entry for schedule:run exists on the host; (3) withoutOverlapping() isn't leaving a stale lock in cache; (4) the queue worker is actually up if it's a ->job() entry.

Config quirks. Publish and inspect the framework config before assuming defaults:

php artisan vendor:publish --tag=netflex-config

Look for scheduler-specific keys (timezone, lock store, queue connection). A mismatched timezone between the app config and the server's cron is the single most common cause of "it ran at the wrong time" reports.

Extension points to look for in src/:

• A service provider with register() / boot() — where the schedule is wired.
• Events dispatched around task execution — hook these for audit logging rather than wrapping every command.
• An interface or abstract class for tasks — implement it rather than duck-typing.
• Any config/ or resources/ directory shipped in the package — these reveal intended usage.

Compatibility risk. With zero dependents, you are one of very few people running this combination. Assume Laravel-version bumps may break it before they break mainstream packages. Keep a smoke test that runs schedule:list in CI so an upgrade failure shows up at build time, not at 2 a.m. when a cron silently stops firing.

When to reconsider. If your scheduled workload is simple, you may not need this component at all — plain Laravel Schedule covers most cases. Reach for the Netflex scheduler specifically when you need its site-aware registration or its framework integration. Otherwise you're taking on an undocumented, unsupported dependency for no gain.