1.18.0 - Add every(interval) feature, Implement sequential execution of jobs with a single worker

What's Changed

Add every(interval) feature by @bottlehall in #146
Implement sequential execution of jobs with a single worker by @bottlehall in #147

Adds a new feature to enable jobs to be scheduled using intervals of seconds, minutes, hours, days or weeks.

Examples:

.every(seconds: 3)
.every(minutes: 17)
.every(hours: 5)
.every(days: 4)
.every(weeks: 6)

Adds the ability to specify the number of workers assigned to an individual queue from one to the default system-wide maximum.

Setting the queue's workerCount parameter to one ensures that jobs execute one at a time. A further change was to implement popFirst to replace popLast to give the more intuitive FIFO behaviour instead of LIFO.

An extended test ensures that two jobs submitted to the queue before it is started will execute in the order of submission and first completes before the second commences.

This patch was released by @gwynne

Full Changelog: 1.17.3...1.18.0

1.17.3 - Fix scheduled job double-fire caused by NIO timer jitter

What's Changed

Fix scheduled job double-fire caused by NIO timer jitter by @bottlehall in #145

On some platforms (n my case, Fly.io’s Firecracker microVMs), NIO’s monotonic clock can fire a large-delay timer slightly early. For example, when a daily job is scheduled for 20:00:00 and the timer fires at 19:59:59.8, the job runs as expected. However, the subsequent call to self.schedule(job) then called scheduler.nextDate() with no argument, defaulting current to Date() which is still 19:59:59.8-ish. Because 20:00:00 is still in the future from that reference point, nextDate returns 20:00:00 again, causing the job to fire a second time ~200ms later. The fix passes the originally-scheduled date to the next schedule call so that nextDate(current:) always advances to the following occurrence rather than potentially returning the current one. Two small changes:

AnyScheduledJob.Task gains a scheduledDate: Date field so the scheduled date can be threaded through the completion handler. AnyScheduledJob.schedule(context:after:) accepts an optional previousDate and uses it (falling back to Date() on the first call…

This patch was released by @gwynne

Full Changelog: 1.17.2...1.17.3

1.17.2 - Use String(reflecting: error) for error logging

What's Changed

Use String(reflecting: error) for error logging by @gwynne in #141

This allows for, in particular, Postgres errors to be meaningfully reported in the log, which at this time is otherwise impossible. Also bumps the Swift min to 5.10

Reviewers

Thanks to the reviewers for their help:

• @MahdiBM
• @ptoffy

This patch was released by @gwynne

Full Changelog: 1.17.1...1.17.2

1.17.1 - Don’t set `delayUntil` if there is no delay

What's Changed

Don’t set delayUntil if there is no delay by @wfltaylor in #140

Currently, if a job is retried with no delay, the delayUntil property is set to the current time. I noticed this since it was causing some issues with a new test in vapor-community/vapor-queues-fluent-driver#15. This PR adjusts this so that delayUntil is nil when there is no retry delay. This aligns the behaviour with how new jobs with no delay are created.

This patch was released by @gwynne

Full Changelog: 1.17.0...1.17.1

1.17.0 - Add Meter for in-progress jobs

What's Changed

🚨The jobDurationTimer metric has been updated to use milliseconds rather than seconds.

Add Meter for in-progress jobs by @ptoffy in #139

This adds a Meter metric to record the number of jobs currently being processed by a worker.
The gauge also allows calculation of not yet processed but enqueued jobs, since we can now do

notYetProcessedJobs = dispatchedJobsCount - (errorCompleted + successCompleted) - inProgressJobs

Reviewers

Thanks to the reviewers for their help:

• @maciejtrybilo

This patch was released by @ptoffy

Full Changelog: 1.16.1...1.17.0

1.16.1 - Fix usage of the Metrics Timer.

What's Changed

Fix usage of the Metrics Timer. by @maciejtrybilo in #135

When using the Timer aggregate the measurements by status and job name rather than by status and job id.

Job id is unique to each job run and therefore in the current implementation a new summary is created for each job run which doesn’t collect useful metrics data and causes excessive memory usage.

Reviewers

Thanks to the reviewers for their help:

• @ptoffy

This patch was released by @0xTim

Full Changelog: 1.16.0...1.16.1

1.16.0 - Added dependency to `swift-metrics`

What's Changed

Added dependency to swift-metrics by @ptoffy in #117

Added a dependency to swift-metrics to be able to record metrics on queues.

Metrics added:

• Timer to see how long a job takes to complete
• Counter to keep track of dispatched jobs
• Two different counters to keep track of successes and failures

This patch was released by @0xTim

Full Changelog: 1.15.1...1.16.0

1.15.1 - Run until no more work is pending

What's Changed

Run until no more work is pending by @danpalmer in #134

First pass at fixing #124.

Currently, every refresh interval, workers run a single task. This means that the maximum task throughput in the refresh interval is the number of workers.

With this change, every refresh interval, workers run tasks until there are no more tasks. This means that task throughput is tied to the speed of processing tasks, rather than just the number of workers.

Open to feedback about the approach, and I haven’t added any tests here yet. This is a fairly major behavioural change, but should result in a large speed increase for most users.

This patch was released by @0xTim

Full Changelog: 1.15.0...1.15.1

1.15.0 - Making Queues `Sendable`

What's Changed

Making Queues Sendable by @gwynne in #129

The Queues package is now Sendable-correct. Also includes a number of fixes:

• Swift minimum version is now 5.8 of course
• QueuesCommand now does signal handling the same way ServeCommand does.
• The logging is much more consistent and is fully structured
• QueueWorker now handles retries in a much more consistent fashion and always requeues.
• AsyncQueue now exists for creating Concurrency-based drivers

Reviewers

Thanks to the reviewers for their help:

• @MahdiBM
• @0xTim

This patch was released by @gwynne

Full Changelog: 1.14.0...1.15.0

1.14.0 - Adopt Async Lifecycle Handler

What's Changed

Adopt Async Lifecycle Handler by @0xTim in #132

Adopt Vapor’s asynchronous LifecycleHandler APIs to avoid calling .wait() in the main application flow

This patch was released by @0xTim

Full Changelog: 1.13.0...1.14.0