This is not a good approach, imo. With the information you gave no one can tell whether it’s because of a genuine bug or because of a misstep while using the library. If you want to air something out like this you should be willing to work through the details to get to the truth.
joey_the_snake
sergio
For our use case we absolutely want to be inflexible and not have multiple jobs. Oban did not respect the unique setting one way or another, and the only real way for us to guarantee uniqueness was through this database unique index.
What we are looking at next is try to catch these attempts at inserting dupes and tracing that back to try to figure it out. @slouchpie is very thorough and if he doesn’t share additional things is because we really don’t have anything additional to report, it’s quite a mystery.
As it stands, make sure you add a unique database index or you will somehow get dupe jobs.
sorentwo
Oban Core Team
But you haven’t shared any additional information to help diagnose the underlying issue. Instead, you’re giving contrary advice based on your assumptions about a bug.
Unique jobs is an older feature and I’ve never heard of this bug before (let alone crashes within a transaction causing writes to the database). If you truly feel that this is because of a bug in Oban, then please share additional information so we can diagnose it and potentially fix it for others.
With the information that I have currently it doesn’t look like an Oban issue at all, and you’re spreading FUD rather than collaborating.
10
lud
Hi @sorentwo , is it possible to add logic to the job uniqueness feature?
For instance if we want to perform long operations when user data has changed, we may use a job with the following flags:
- job 1
[flag_1: true, flag_2: false] - job 2
[flag_1: false, flag_2: true]
The uniqueness would be used to debounce the long operation.
Now, is it possible to have [flag_1: true, flag_2: true] in the end ?
Thank you.
sorentwo
Oban Core Team
Unique jobs have a lot of complexity around querying and replacement already, and I’d prefer not to add more.
I’d look at modeling your problem using more nuanced args/meta and a ‘replace` option.
lud
laiboonh
Hi, i am a new Oban user. I am running a system with multiple nodes one database. Trying to understand the section on job uniqueness Oban — Oban v2.23.0. From what i understand there is a default 60 seconds :period for which a job will be considered unique.
So say my system has nodes A,B,C. If A,B,C all triggered the same scheduled job (all running same codebase and hence Oban config), one of them will hit the DB first and then the other two will be rejected because of a lock for 60 seconds.
Then why would i need to code stuff like use Oban.Worker, unique: [period: 300, states: [:available, :scheduled, :executing]]?
laiboonh
I am definitely misunderstanding something. I did
Enum.each(1..10, fn _i ->
%{id: 1, in_the: "business", of_doing: "business"}
|> MyWorker.new()
|> Oban.insert()
end)
All this happens within 60 seconds, i was expecting to see only 1 job but i see 10
Update:
This quoted paragraph below is misleading. It seems Oban does not have any defaults at all. I needed to specify use Oban.Worker, unique: [period: 60] to get the behaviour i expected
:period — The number of seconds until a job is no longer considered duplicate. You should always specify a period, otherwise Oban will default to 60 seconds. :infinity can be used to indicate the job be considered a duplicate as long as jobs are retained.
cmo
Are you assuming that uniqueness is set by default rather than, if you enable unique jobs, the default period is 60s?
zachallaun
I believe that default 60s would apply if you specified unique: true, or if you specified unique with other options but not period explicitly.
It does not make sense for all jobs to be unique by default.