ArithmeticError from globally limited queue

Special Sections Oban
,
1

We’re experiencing an intermittent ArithmeticError in production with Oban Pro 1.6.5 and could use some guidance on what might be causing it. The error occurs in Oban.Pro.Limiters.Global.merge/2 at line 30:

** (ArithmeticError) bad argument in arithmetic expression
:erlang.+(%{"..." => %{}, "..." => integer(), "..." => nil}, %{"..." => %{}, "..." => integer(), "..." => nil})
(oban_pro 1.6.5) lib/oban/pro/limiters/global.ex:32: anonymous fn/3 in Oban.Pro.Limiters.Global.merge/2

What caught our attention is that the tracked map appears to contain mixed types: empty maps %{}, integers, and nil values. The merge/2 function assumes all values are integers when it tries to add them. We’re using global_limit on several queues (some with partitions, some without).

We haven’t been able to reliably reproduce this locally, and it seems to happen sporadically in production. We’re wondering: is there a known scenario where tracked could legitimately end up with nil values? Could this be related to upgrading between Oban Pro versions, or perhaps something with the update_legacy_tracked/1 function? Any pointers on what conditions might trigger this would be really helpful.

Thanks for any insights!

2

This is the most likely scenario. Did you upgrade from a version of Pro < 1.6 recently? Are you running multiple Pro versions at the same time?

3

No, we track each release very closely.

4

The values should all be integers, unless there’s mixed data somehow.

Will you please send your config for the queue in question, and the results of select * from oban_producers where queue = ‘QUEUE NAME’ to support@oban.pro?

5

@sorentwo Apologies - I misdiagnosed this. After checking production, the ArithmeticError is actually coming from ExAws’s backoff logic, not from Oban Pro’s limiter. Sorry for the confusion!

6

No problem! I’m please to hear you figured it out (and there’s nothing we need to fix!)

2 Likes