Job Status Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for async job UX. Long-running work (bulk imports, CSV exports, report generation, image/video transcoding, ERP/WMS syncs) is where users lose trust and file support tickets. This bundle is a concrete reference design for the "job status" layer: a stable identifier per job, a lifecycle of states (pending → running → finished/failed), percent progress, and a persisted record a UI can poll. Framing the decision as "adopt, fork, or replicate the pattern in-house" is more useful than treating the package as a binary dependency choice.
• Roadmap sequencing for a "job activity" surface. If you're planning a status/progress UI (account activity page, admin job monitor, "your export is ready" notifications), this tells you the minimum data model required — and that you can ship it thin. It also flags the follow-on asks that arrive right after launch: cancellation, retry, ETA, partial-failure reporting, notifications on completion. None of those are in scope here.
• Feature scope discipline. The package deliberately abstracts progress only. It is not a queue, not a scheduler, not a retry engine, not an observability tool. Use it to draw a clean line: queue infrastructure stays with the queue runtime; the customer-facing state machine and its persistence is our product surface.
• Ops/support cost reduction as a decision input. The measurable win is fewer "is it still running?" tickets and fewer duplicate submissions. If your current answer to that question is "refresh and hope," the status abstraction pays for itself quickly regardless of whether this specific library is adopted.
• Vendor/architecture risk is a first-class factor in the decision. With 0 stars, 0 dependents, and a release history that went dormant after May 2022, adopting this as a production dependency remains a maintenance liability, not a shortcut. The new v0.2.5 ("Fixed memory issues with commands") is a genuine but very narrow maintenance signal — a patch-level bugfix to the Symfony command integration, not a feature release, not a compatibility statement against current PHP/Symfony versions, and not evidence of a restored release cadence or a maintainer team. The realistic decision it supports is still "use as a design reference under MIT, implement the ~200 lines we actually need."

When to Consider This Package

Consider it when:

• You are on Symfony (not Laravel) and dispatching async work through Symfony Messenger or a similar worker model, and you want a small, framework-native abstraction rather than hand-rolling status fields.
• Your requirements are genuinely thin: a job ID, a state, a progress number, and a way to look it up. No retries, no fan-out, no ETA, no cancellation.
• You need persistence-backed status that survives a page reload and is readable from a controller — i.e., a polling-friendly, server-rendered UI rather than a real-time/push experience.
• You are comfortable treating it as source to fork, not a package to depend on: MIT license, tiny surface area, so vendoring or copying the pattern is low cost and removes the abandonment risk. v0.2.5 slightly improves the fork calculus — the command-side memory fix is worth cherry-picking if you vendor the command/worker code.

Look elsewhere — or build instead — when:

• You are on Laravel. This is a Symfony bundle; it does not install or work in a Laravel app. The transferable value is the pattern, not the code. Laravel already gives you Job/Batch primitives, queue events, and Horizon for monitoring; a thin job_statuses table plus a broadcast event is likely less work than adapting a foreign abstraction. Note that the only thing fixed in v0.2.5 is Symfony command memory behavior — zero relevance to a Laravel build.
• You need production-grade reliability. Zero stars, zero dependents, and a dormancy of roughly two years broken only by a single patch release means no community, no security response, and no stated compatibility guarantees with current Symfony/PHP versions. One bugfix does not change the risk profile; budget real time for a version bump if you try to install it.
• Your real problem is observability, not UX. If what you actually need is tracing, failure alerting, and throughput dashboards, that is Horizon / Sentry / OpenTelemetry / Messenger middleware territory. This package will not help.
• You need real-time updates. Polling-only status is fine for minute-scale jobs; for anything interactive you want websockets/SSE and a broadcast-on-transition design, which is outside this package's scope.
• You need multi-tenant scoping, job cancellation, or idempotency guarantees — none of that is covered, and you'd be extending a base that has shipped one patch in two years.

Recommendation: Do not adopt as a dependency. Do read it as a 30-minute design reference and treat it as evidence that the in-house build is small: one table, one enum, one service, one polling endpoint. v0.2.5 is a memory-leak fix in the Symfony command path — welcome if you fork, immaterial to our decision. The opportunity score (41.67) and adoption numbers are consistent with a useful idea that never found a sustained maintainer — the idea is worth stealing, the package is not worth depending on.

How to Pitch It (Stakeholders)

To executives: Users don't trust processes they can't see. Today, long-running work in our product is a black box — they click, they wait, they refresh, they file a ticket, some of them click again and we do the work twice. A "job status" layer is a small, well-understood capability that fixes that: every async task gets an ID, a state, and a progress indicator the user can check. The cost is modest and the payoff is measurable in support volume and duplicate-work reduction. A relevant MIT-licensed Symfony bundle exists that solves exactly this, which is useful evidence the problem is common and the solution shape is settled — but that package has effectively no adoption and went roughly two years without a release before a single bugfix patch last cycle, so the right move is to implement the pattern ourselves rather than take on the dependency risk. Net: green-light a small, scoped build; do not budget for a purchase or an integration.

To engineering: This is a scope-defining artifact, not a vendor proposal. It shows the minimal contract — job identity, state machine, progress, persistence, lookup — and by omission shows what we must own ourselves: queue semantics, retries, cancellation, tenant scoping, real-time delivery, and alerting. Expect a handful of files: a status enum, a small persisted model, a service that transitions state, and an endpoint for the UI to poll. If we go real-time, add broadcast-on-transition. Ignore the Symfony coupling; we're taking the design, not the code. The latest release (v0.2.5) is only a memory fix in the bundle's command layer — no API surface change, nothing for us to track. Please also call out where progress reporting belongs so it doesn't leak into every job class — that's the one place this design can go wrong at scale.