Feedback on Oban Pro: Missing Backport of Important Bug Fix

Special Sections Oban
, ,
1

We recently upgraded from Oban Pro 1.4 to 1.5. The migration itself went smoothly, and everything seemed stable at first. However, we soon began experiencing frequent crashes related to clear_uniq_violation/3 being passed a list of atoms.

After investigating, we discovered that this issue was already fixed in Oban Pro 1.6. Unfortunately, the fix wasn’t backported to 1.5, which would have prevented this problem entirely on our end.

I understand that maintaining multiple versions can be complex, but it would have spared us from some stress. I’d like to raise this as a point of feedback and suggest considering backporting critical bug fixes to minimize friction for teams that can’t upgrade to the latest version immediately.

Thanks for your work on Oban.

1 Like
2

Sorry you encountered issues after the v1.5 upgrade. Accurate, transactionally safe, index backed uniqueness can cause issues with custom unique configurations.

We don’t have an official backport/support policy, but in general, once a new minor version is released we stop applying smaller bugfixes to older versions. If it’s a critical bug then we’ll backport, as we did for the issues in v1.5.4, but not for edge cases or smaller bugs.

The issue you encountered was considered an edge case that would only happen for certain unique configurations (most likely configurations that don’t actually prevent uniqueness). This is related to a support issue posted yesterday: Oban jobs stuck at "scheduled" and then "available" if I move them there manually - #4 by sorentwo

The best fix for this issue is to ensure that if you’re going to include executing, you list all incomplete states:

states: ~w(available scheduled executing retryable)a

Remember, uniqueness applies on insert only. Jobs are always inserted as available or scheduled, so a unique config without those states won’t prevent any inserts, it will just cause processing issues later on.

2 Likes
3

Thanks for your reply ! good to know, I wasn’t aware of the policy.

in case someone stumbles on the same problem, pasting the exception here.

Ecto.Query.CastError: deps/oban_pro/lib/oban/pro/engines/smart.ex:783: value `[:scheduled, :available, :executing, :retryable, :completed, :discarded, :cancelled]` in `where` cannot be cast to type {:in, :string} in query: