- Can I use setono/job-status-bundle in a Laravel application?
- No, not as-is. It is a Symfony bundle built on Symfony's Bundle and DI extension model with Doctrine ORM persistence, so there is no service provider, config bridge, or facade that Laravel could consume. Running composer require on it inside a Laravel app will not give you a working integration, and the 2022-era Symfony version constraints will likely conflict with a current Laravel stack anyway.
- Is setono/job-status-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, published as setono/job-status-bundle on Packagist. The problem it solves — a durable record of an async job's lifecycle from queued to running to complete or failed, with timestamps and error context — is completely framework-agnostic. So the value for a Laravel team is the domain model and design pattern, not the shipped code.
- How do you install setono/job-status-bundle?
- In a Symfony application you would require it via Composer, register the bundle in config/bundles.php, and provide Doctrine ORM configuration plus a schema migration for the status table. There is no Laravel installation path. Before attempting the Symfony route, check the package's composer.json constraints against your Symfony and PHP versions, because the last tagged release is from May 2022.
- Which Symfony and PHP versions does setono/job-status-bundle support?
- The published constraints date from the 2022-05-13 release, so the Symfony ceiling is likely below current LTS lines and the PHP requirement probably lags modern 8.x releases. Treat those constraints as aspirational rather than tested until you verify them in CI. If you are on a maintained Symfony LTS, expect to fork and bump constraints yourself.
- How would I implement job status tracking in Laravel without this bundle?
- Treat the repository as a reference design and reimplement the pattern natively. Create a job_statuses table with a UUID, job class or type, status enum, progress (0-100 or a step counter), message, serialized context, started_at, finished_at, heartbeat_at and attempt count, then add an Eloquent model plus a small repository. Wire a job middleware or queue event listeners on JobProcessing, JobProcessed, JobFailed and JobExceptionOccurred to create and transition records, and define a progress-reporting contract that long-running jobs opt into. A focused engineer can produce a production-quality minimal version in roughly 3 to 10 days excluding UI.
- Does this replace Laravel Horizon or queue monitoring?
- No, they address different concerns. Horizon already exposes queue-level health, recent job inspection, tags, and wait and runtime metrics, whereas this package is about per-job business-process progress that an end user is waiting on. Confirm your team is not solving a problem Horizon already covers before investing in a port.
- Is persistence mandatory, or can I store job status in Redis or Eloquent?
- Based on the description and typical Setono patterns, the bundle persists status records through Doctrine ORM rather than a storage-agnostic interface, so you would need to verify that in the source before assuming otherwise. Pulling Doctrine into a Laravel app is a real conflict surface, since Doctrine DBAL is often present only for migrations tooling. A native port lets you choose Eloquent, Redis, or both freely.
- What transport does it hook — Symfony Messenger, Enqueue, or something else?
- The description does not specify, and this is one of the key questions to answer in a spike before porting. Whether it integrates with Symfony Messenger, Enqueue, or an internal abstraction determines how much of the porting surface you actually need to reimplement. In Laravel the equivalent hooks are the queue events JobProcessing, JobProcessed, JobFailed and JobExceptionOccurred, or a job middleware.
- Is setono/job-status-bundle actively maintained?
- No. The last release is 2022-05-13 with zero stars and zero dependents, which means no community validation, no issue triage, and no security response path. There will be no upstream fix for anything you find, so any adoption is effectively a fork you own. Use it as a design reference rather than a long-term dependency.
- How do I test job status tracking and handle concurrency, retries, and dead workers?
- Use Laravel's queue fakes to assert that a status record is created on dispatch and transitions correctly to its terminal state on both success and failure. Concurrency and correctness need explicit attention: status writes from parallel workers on the same record, retry and duplicate-delivery semantics, and whether progress updates are transactional with business state are all unresolved until you verify them yourself. Add a heartbeat_at timestamp with an expiry sweep so jobs whose worker died do not stay stuck as running, and index the table plus define retention if end users poll dashboards.