feat(oban): add option to include job tags into reported exception tags

[adriencohen]

Description

Added an oban_tags option to the oban configuration to include a job's tags in the tags of the Sentry issue created. The goal is to have ownership rules based on the tags of an Oban job.

This is likely not ready to merge as is at least more thought needs to be put into the configuration option. Should we consider changing capture_errors into a keyword list, similar to cron? That would be a breaking change.

I'm opening this PR mainly to discuss whether you’d consider such a feature.

Thank you!

[adriencohen]

Hi @solnic, sorry for the ping, but do you think this proposition has any chance of happening?

[whatyouhide]

I think it's fine to add this as a separate boolean to the config. Changing :capture_errors to be a keyword list would make the main "turn on" option awkward:

capture_errors: [
  enabled: true, # ? Whatever I think here sucks
  tags: true
]

However, I think we should rename :oban_tags to :add_oban_tags_as_tags or something more explicit.

Another question: if we report this as a single Sentry tag like oban_tags → tag1,tag2, aren't we missing out on being able to manipulate tag1 and tag2 individually in Sentry itself? Should we instead report those as

%{
  "oban_tags.tag1" => true,
  "oban_tags.tag2" => true
}

?

[adriencohen]

Thank you @whatyouhide for looking into it, I renamed the option to :add_oban_tags_as_tags in my last commit.

Regarding how we report those tags to Sentry I really like your suggestion and it fits my current use case perfectly. However, there are a couple of caveats worth considering:

1. Pattern matching limitation: This approach doesn't allow matching by pattern in Sentry, as pattern matching can only be done on tag values. But I don't really see when you would need that.
2. Tag key constraints: Once this feature is enabled, all Oban tags would need to conform to Sentry's tag key limitations This could become problematic depending on how developers use their Oban job tags.

Alternative approach: We could leave this decision to developers by allowing them to provide a transformation function. For example:

oban_tags_to_sentry_tags: fn job -> 
	["oban_tags": Enum.join(job.tags, ",")]
end

or your version

oban_tags_to_sentry_tags: fn job -> 
	Map.new(job.tags, fn tag -> {"oban_tags.#{tag}", true} end)
end

I think this is up to you to decide which way we should go