Command Lock Bundle Laravel Package

Product Decisions This Supports

• Duplicate-execution risk in scheduled work. The underlying problem — the same command running twice concurrently because a cron fired while the previous run was still going — is a real, expensive class of bug: double-sent invoices, duplicated report emails, race conditions on inventory or balance updates, overlapping ETL jobs corrupting a table. Any roadmap item touching batch jobs, nightly syncs, or customer-facing notifications depends on an answer to "what stops a second run?"
• Build vs. buy for a job-safety layer. This package is a candidate "buy" (MIT, drop-in) against a "build" of ~50–200 lines of file-lock or cache-lock code. The decision hinges on whether the framework already ships the primitive — and in Laravel it does (withoutOverlapping() on the scheduler, Cache::lock(), unique jobs). That largely collapses the build-vs-buy question into "use native."
• Framework fit is a gating decision, not a detail. Despite being catalogued as a Laravel/PHP package, this is a Symfony bundle (2014-era, Symfony 2.x bundle conventions). It is not the right shape for a Laravel application; adopting it means pulling a foreign bundle structure and its transitive assumptions into a Laravel app. For a Symfony shop, it's plausibly relevant — for a Laravel shop, it's a category error.
• Maintenance/dependency policy decisions. Last release 2014-06-02, 5 stars, 0 dependents. This is an unmaintained artifact. Adopting it forces a decision about your stance on abandoned dependencies (no PHP 8 compatibility, no security response, no Symfony 5/6/7 support) — which is really a governance decision your team should make once and apply consistently.
• Use cases it maps to, if the primitive is right: single nightly report generator; a webhook consumer that must not double-process; a data import triggered both by cron and manually; any command where "two at once" is a correctness bug rather than a performance annoyance.

When to Consider This Package

Consider it only under narrow conditions:

• You maintain a legacy Symfony 2.x application (circa 2013–2015, PHP 5.x) that already depends on it, and the decision is "leave it alone until the platform migration" rather than "adopt it."
• You need a single-host, process-level lock and you explicitly do not need distributed locking across multiple app servers or containers.
• You've confirmed it installs and runs against your actual PHP/Symfony versions — do not assume it does.

Look elsewhere in the far more likely cases:

• Laravel application → use the framework: $schedule->command(...)->withoutOverlapping(10), Cache::lock() with a Redis/DB store, or ShouldBeUnique queue jobs. Zero dependencies, maintained, documented, and it handles lock expiry — a thing ad-hoc implementations routinely get wrong.
• Modern Symfony → symfony/lock is a first-party component that supersedes this bundle entirely.
• Multi-server / containerized deployment → you need a shared lock store (Redis, database, DynamoDB). A local file lock gives you false confidence when three pods are running cron.
• You need observability → no metrics, no lock-contention logging, no alerting here. If "why did this job skip?" needs an answer at 2am, this package doesn't give it.
• Anything requiring a security or compatibility review → an eleven-year-old package will not pass one. Expect this to be blocked by any reasonable dependency-scanning gate.

How to Pitch It (Stakeholders)

Bottom line: the problem is worth solving; this package is not the way to solve it.

For executives: We have a genuine reliability exposure — scheduled jobs and batch processes can run twice at the same time, which risks duplicated customer communications, double-counted transactions, and corrupted data. There is a small open-source library that addresses this, but it is a 2014-era Symfony bundle with five stars, no downstream users, and no release in over a decade — it won't run on a current PHP stack and won't survive a security review. The good news: the frameworks we already pay for solve this natively. Recommendation is to standardize on the built-in locking primitives, not to take on an unmaintained dependency for a problem we can close in about a day of engineering.

For engineering: Treat the repository as a specification, not a dependency — it tells you someone had this problem and the fix is "acquire a lock before the command body, release on exit, handle the case where the holder died." Implement that intent with what we already have: withoutOverlapping() on scheduled commands, Cache::lock() for on-demand guards, unique queue jobs where relevant. Requirements we should hold ourselves to: lock must be released on crash (TTL, not just finally), must work across all app instances (shared store, so Redis or DB — not local files), and must log when a run is skipped so the behavior is debuggable. Note the catalog lists this as a Laravel package; it is actually a Symfony bundle, which matters if anyone proposes it as a drop-in.