5.3.0 — Immediate re-poll via PollScheduler

Due-job polling now runs through netlogix/jobqueue-polling's PollScheduler: in addition to the periodic interval, a freed worker slot triggers an immediate re-poll, so the next due job is picked up without waiting for the next tick.

New dependency: netlogix/jobqueue-polling.

5.2.1 - Ensure only 1 job is claimed for PostgreSQL

What's Changed

• fix: Ensure only 1 job is claimed for PostgreSQL by @paxuclus in #40

Full Changelog: 5.2.0...5.2.1

5.2.0 - Add Job Status Service

What's Changed

• feat: add job status service by @HenrikVogel in #38
• fix: doctrine transaction and unified timeout setting by @HenrikVogel in #39

Full Changelog: 5.1.1...5.2.0

5.1.1 - Fix PostgreSQL stale job reset

Merge pull request #37 from netlogix/fix/postgres-reset-stale

5.1.0 - Add signal for failed jobs

Merge pull request #36 from netlogix/feat/fail-signal

5.0.0 - Introduce PostgreSQL support

Adds native PostgreSQL support and refactors the scheduler into
database-specific implementations with dedicated SQL dialects
and migrations.

The job running state is now treated as a multi-state value in PHP,
aligning the code with the existing database representation.

4.0.0 - Use React/Loop and React/Process for job execution

Switches to netlogix/jobqueue-pool to:

• execute jobs async,
• keep the DBAL connection alive while waiting, and
• update the job database row to keep track of "activity".

This makes use of React/Loop and React/Process.

Updating the "activity" every couple of seconds allows determining whether a given job is currently stalled.

3.3.2 - Retry "retryables" up to 5 times when scheduling

Scheduling new jobs sometimes fails due to database deadlocks. These are "retryable", so the system will simply try again.

3.3.1 - Duplicate Job Execution in Multi-Worker Setups

Jobs can now be scheduled to run again only after the previous execution has fully completed.

In a multi-worker setup, the previous implementation could allow a new worker to start the same job while it was still running on another worker. This behavior was typically undesired and could lead to race conditions or duplicate processing.

With this fix, a new instance of the job is only started once the current instance is no longer marked as running.

3.3.0 - Improve resilience against deadlocks during job claiming

Claiming unclaimed jobs already attempts to make optimal use of available indexes.
However, deadlock exceptions can still occur and cause the worker process to fail,
even though these exceptions implement Doctrine's RetryableException interface.

This change introduces a retry mechanism that performs up to 5 additional attempts
with exponentially increasing wait intervals between each try.