Oban — Reliable and Observable Job Processing

Special Sections Oban
, , ,
184

Oban v1.1.0 is out with some minor features and a ton of reliability improvements prompted by edge cases from real world usage. Thanks to everybody that reported the issues and helped in proving the solutions :yellow_heart:

From the CHANGELOG:

Fixed

  • [Oban.Crontab] Allow any number of spaces and/or tabs in cron expressions.

  • [Oban.Pruner] Prevent deadlocks while pruning by ensuring that only a single node can prune at any given time. (Thanks @bgentry)

  • [Oban.Queue.Executor] Improve handling of nested/linked process failures. Previously if a job spawned a process that crashed (i.e. through Task.async) then the job was left stuck in an executing state.

Added

  • [Oban.Worker] Add timeout/1 callback for limiting how long a job may execute. The default value is :infinity, which allows a job to run indefinitely and mirrors the previous behavior. (Thanks to @benwilson512 who did the initial implementation)

  • [Oban.Telemetry] Add :error and :stack to trip_circuit event metadata.

  • [Oban.Queue.Executor] Retry success/failure database updates after a job finishes.

    On occasion something may happen to the database connection and updating a job’s state would fail. Now we retry writing with a linear backoff to prevent the job from getting stuck in an executing state. (Thanks to @coladarci)

Changed

  • [Oban.Worker] Tighten the spec for perform/2. Now workers are expected to return only :ok, {:ok, result} or {:error, reason}. A warning is logged if any other value is returned—for high throughput systems this may cause performance issues and you should update your worker’s return values.

    Returning a success tuple is supported for testing purposes and backward compatibility, while returning :ok on success if preferred. (Thanks to @sasajuric)

13 Likes