All Versions
Latest Version
Avg Release Cycle
40 days
Latest Release

Changelog History
Page 1

  • v6.1.1 Changes

    🛠 Fixed processing a subset of scheduled jobs.

  • v6.1.0 Changes

    May 17, 2018

    You can process a subset of queues in a given Ironium process. 👀 See README for configuration.

  • v6.0.0 Changes

    February 02, 2018

    👍 Now supporting AWS SQS.

    🛰 Handlers now receive their own copy of the job payload.

    👷 We now debug-log the full job in case of error. When using SQS, this includes 👷 the receipt handle, which can be used to delete the job.

    ⏱ Schedules now get their own queue.

    ✅ IronMQ still supported, but untested, unless you bring your own iron.json.

  • v5.0.0 Changes

    Concurrency is now a global limit, shared by all queues.

    🔧 Concurrency can be configured via the IRONIUM_CONCURRENCY environment 0️⃣ variable. Default is 50.

    ✅ Delayed jobs can be tested by time traveling.

    ⏱ A scheduled job's time-to-live is equal to its interval. This better matches expectations on transient error conditions.

  • v4.1.3 Changes

    Ironium will honor BEANSTALKD_HOSTNAME and BEANSTALKD_PORT environment variables if present.

  • v4.1.2 Changes

    👍 Allow Ironium to be installed on newer versions of Node.

  • v4.1.1 Changes

    👷 Failed jobs were not being returned to the queue with a delay when using IronMQ.

  • v4.1.0 Changes

    ⏱ Minimum interval for scheduled jobs is one minute. Ironium was never designed for short intervals; this change only makes that explicit.

  • v4.0.0 Changes

    ➕ Added processing concurrency. By default, Ironium will run 10 concurrent jobs. 🔧 This can be configured via the concurrency option.

    👷 Multiple jobs can be queued in a single API call: Queue#queueJobs(jobs).

    ⬇️ Dropped support for callbacks and generator functions. Job handlers must return a promise now.

  • v3.2.2 Changes

    🛠 Fixed bug in error handling when queuing scheduled job.