This may indicate a unique job misconfiguration where jobs are being inserted
with conflicting unique keys across different states. The engine repaired the
violation for uniq_key: CQIR8lrkVLDcIwX6d6zP39W26pjX29phw36yxi2bSAY
Check your unique job configuration to ensure the :states option matches the
expected job lifecycle for this worker.
Oban Pro 1.6.11 on Elixir 1.9.4
Am getting the above error in my log file, but not sure what worker or how to find the worker for this error. Would like to drill in and correct the root cause. Any guidance about how to locate the worker would be appreciated.
Never mind - found the job by searching with ObanWeb on meta:uniq_key.
1 Like
That’s the way to do it! Fixing the situation should be as simple as changing the states for that unique config (Changelog — Oban v2.20.3)
In this case I have most jobs running immediately but uniquely.
````
use Oban.Pro.Worker,
queue: :tasks,
priority: 2,
# do not add :scheduled to this list as longer term scheduled jobs may
# exist that are scheduled for timeline purposes
unique: \[period: {2, :minutes}, states: \[:available, :retryable\]\],
max_attempts: 3
```
but some future jobs (multiple days ahead typically) that are using :scheduled_at
So I think those future jobs need an overriding definition for :unique.
Hope I am thinking about that correctly.
Yes, you can override unique when you insert the job. Your thinking seems correct.
Having available without scheduled will cause these unique violations. There’s a conflict when the scheduled job transitions. Having that config will cause that problem.
Here are some options as we see them:
-
Change the definition to consider scheduling
-
Stop using uniqueness (I know we say that often but it’s usually the answer)
-
Customize the unique instance when you insert