feat(hangfire): send the recurring job's cron schedule as the monitor config

[wedamija]

Description

Adds a SendMonitorConfig option to the Hangfire integration. When it's on, the in-progress check-in of a recurring job includes the job's cron and time zone as the monitor config, so Sentry creates the monitor or updates its schedule. The slug still comes from [SentryMonitorSlug].

It's on by default. To turn it off:

GlobalConfiguration.Configuration.UseSentry(o => o.SendMonitorConfig = false);

When the schedule can't be represented exactly in Sentry (seconds other than a fixed value, day fields Hangfire combines differently, a time zone with no IANA ID), the check-in goes out without a config, as today, rather than with a schedule that would cause false missed-check-in alerts.

Hangfire jobs are only monitored when they already have [SentryMonitorSlug], so the user has opted in to monitoring, and the recurring job already knows its schedule. Sending it by default lets Sentry create or update the monitor, the same as the Spring and Quartz integrations. On upgrade, existing monitors get their schedule and time zone from the recurring job; set SendMonitorConfig = false to keep managing them in Sentry.

Motivation

Check-ins for a monitor that doesn't exist yet are dropped, so today every Hangfire monitor has to be created by hand, with its schedule copied from the recurring job. The schedule is already in Hangfire, so the SDK can send it.

Testing

ServerFilterTests and HangfireTests.

Docs: getsentry/sentry-docs#19781

[codecov]

Codecov Report

❌ Patch coverage is 94.80519% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.36%. Comparing base (ea7fa3a) to head (96c1d60).
⚠️ Report is 12 commits behind head on main.

Files with missing lines	Patch %	Lines
src/Sentry.Hangfire/SentryServerFilter.cs	93.93%	0 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5665      +/-   ##
==========================================
+ Coverage   74.93%   75.36%   +0.43%     
==========================================
  Files         515      517       +2     
  Lines       18975    19061      +86     
  Branches     3695     3716      +21     
==========================================
+ Hits        14219    14366     +147     
+ Misses       3876     3827      -49     
+ Partials      880      868      -12     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jamescrosswell]

Overall, looks good - I just have one question/suggestion re consistent naming.

The only other thing to note is that if someone deletes a monitor but leaves [SentryMonitorSlug] on the job, the monitor will be recreated on the next run... That's probably OK and better than a monitor that doesn't get created (which we have now). It means people have to remove the slug attribute and redeploy before they can remove a monitor. Any alternative technical workaround would probably have to be a bit more convoluted (leave some trace of the monitor having been deleted on the server).

[wedamija]

Overall, looks good - I just have one question/suggestion re consistent naming.

The only other thing to note is that if someone deletes a monitor but leaves [SentryMonitorSlug] on the job, the monitor will be recreated on the next run... That's probably OK and better than a monitor that doesn't get created (which we have now). It means people have to remove the slug attribute and redeploy before they can remove a monitor. Any alternative technical workaround would probably have to be a bit more convoluted (leave some trace of the monitor having been deleted on the server).

On re-creating deleted monitors: agreed, that's inherent to upsert and works the same in the other SDKs. One other option here is to disable the monitor in Sentry, rather than deleting it. Since the monitor still exists, rather than recreating it the checkins will just be dropped. I can add that to the docs in this pr: getsentry/sentry-docs#19781