Invalid jobs are gracefully inserted but corrupted upon Oban.insert_all of a workflow about oban HOT 6 CLOSED

@naserca Ultimately, I opted for a centralized change to Job.to_map/1 to handle this consistently across all engines. Now all job changesets are validated during insert_all, and it's not possible to mistakenly insert an invalid changeset.

Note that previously sending a value like max_attempts: 0, priority: -1, queue: "", etc. would have raised a Postgrex error rather than an Ecto error. Yes, this may raise in some unexpected situations, but it's more consistent than before.

from oban.

@naserca The recorded: true segment is missing because the job was invalid, and new/2 applies features in stages. Since the structured stage returned an error, the recorded stage didn't run.

The lack of validation during insert_all is a problem that stems from mimicking how Repo.insert_all behaves. We can't change the default behaviour because it would be a breaking change, but we can add an option to Oban.insert_all/3 to force validation. WDYT?

from oban.

I think the insert_all naming (and functionality) while the actual arg is (at least in most cases) a single %Oban.Pro.Workers.Workflow{} struct (and not a bare list of entries as Repo.insert_all expects) might cause confusion and could benefit from something like Oban.insert_workflow or even reusing Oban.insert and Oban.insert!. Curious what you think!

from oban.

Oban is isolated and unaware that Pro exists. We can't add Pro-specific functions to the core Oban module, and Elixir doesn't allow monkey patching (thankfully). Adding an insert_all!/3 variant is a potential alternative.

from oban.

insert_all! seems reasonable! similarly my other suggestions were attempts to avoid "use this function but you have to add this option to avoid a bug" in favor of just "use this completely different function."

from oban.

thanks @sorentwo! makes sense.

from oban.