We should definitely have Oban Pro but my company is still using OSS for now.
Alright, thank you ! (I’ll actually use Process.exit from the test process to assert we are trapping them.)
lud
lud
Hello,
Out of curiosity I was looking at the code of the reindexer plugin. It seems that it is dropping all oban indexes before calling REINDEX on each of them. But how does Postgres know the definition of the index (like the columns for instance) when the index was dropped and the SQL query only contains a name (like REINDEX INDEX CONCURRENTLY "public".oban_jobs_args_index) ?
I can see the indexes definitions in the v10 migration but surely this is not used at runtime.
(I see that the index is dropped only if it is not queryable, but I guess if this clause exists it’s because there are chances).
Thank you
sorentwo
Oban Core Team
It is dropping incomplete indexes that encountered an issue during reindexing. That can happen because the reindex command runs concurrently, without blocking.
It’s a clean up step for previous bad indexes (which aren’t used anyhow). The original, good, indexes aren’t dropped at all.
lud
apoorv-2204
How we deal with module rename of jobs processing?
Do I have to write migrations to deal with renaming of a worker?
gregvaughn
That’s one approach. I find it slightly safer to leave two copies of the module in place under the old and new name until all the jobs referencing the old name complete processing, then delete that module.
sorentwo
Oban Core Team
That’s one way to do it. The other is with two modules, where the old delegates to the new.
Alternatively, with Pro you can use Worker Aliases to seamlessly transition without writing a migration.
apoorv-2204
sorentwo
Oban Core Team
Oban Web will be open source, Oban Pro will not be. Worker aliases are only part of Pro.