Repository navigation
Conversation
size-limit report 📦Compared: de7a020 (PR test merge using develop at a33cba8) Against: a33cba8 (develop) · base run #64006 ✅ Baseline matches: this diff contains only this PR's changes.
|
Sends check-ins for every named node-cron task through the orchestrion createTask channel, with the task's schedule and time zone as monitor config when Sentry reads it the same way. Tasks without a name, and tasks wrapped by Sentry.cron.instrumentNodeCron, are skipped. Co-Authored-By: Claude <noreply@anthropic.com>
Prepares for other scheduler integrations; the helper also handles schedulers that run on either day field (cron-parser, cron). Co-Authored-By: Claude <noreply@anthropic.com>
The error event and the error check-in can arrive in either order. Co-Authored-By: Claude <noreply@anthropic.com>
…-in modules `bun run` can't inject channels into libraries. nodeCronIntegration is opt-in, so it has no lazy channel-integration definition. Co-Authored-By: Claude <noreply@anthropic.com>
2c2c600 to
905ed6b
Compare
…reads differently node-cron 4.0 to 4.2 ship `dist/cjs` and `dist/esm` builds, which weren't instrumented. node-cron 3 keeps the values of a stepped field that are multiples of the step (`*/2` days run on 2, 4, ...), so those tasks now check in without a monitor config. Also moves the channel subscription and job filtering into shared helpers for the other scheduler integrations. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit ffb2c5d. Configure here.
Co-Authored-By: Claude <noreply@anthropic.com>
Optional E2E testsSome optional checks were not successful. They do not block the merge. 2 not successful, 65 successful. See the run.
Successful checks
|
| }); | ||
| } | ||
|
|
||
| /** Whether a job is named, not excluded, and not already monitored by `Sentry.cron.instrument*`. */ |
There was a problem hiding this comment.
is this true? It is set by instrumentCronIntegration I suppose?
| const defined = new Set(CHANNEL_INTEGRATION_DEFINITIONS.flatMap(d => d.modules as readonly string[])); | ||
|
|
||
| // `@nestjs/*` and `@remix-run/*` are covered by listeners in their own SDK packages. | ||
| // Crons integrations are opt-in, so bundler-only SDKs must not install them for every app. |
There was a problem hiding this comment.
we should state here why this is opt in? I guess because this is paid, which makes sense, but is not clear from reading the code.
|
This seems generally good to me, left some small comments, I wonder though, what about bun and deno, should this not be exported and work there too? |
Good call, it looks like we already export this to bun, but I added it to deno. |

Part of a series adding automatic Crons monitoring for the most-used job schedulers in each SDK. Check-ins for a monitor that doesn't exist yet are dropped, so today each monitor has to be created by hand with its schedule copied from the code. Sending the job's schedule as the monitor config lets Sentry create the monitor and keep it in sync.
Adds
nodeCronIntegration, which sends check-ins for every namednode-crontask (3.x and 4.x) with its schedule and time zone as the monitor config. Today each module has to be wrapped inSentry.cron.instrumentNodeCron; with this, adding the integration is enough. It is not a default integration. Tasks without anamearen't monitored.Schedules Crons can't express, like every 10 seconds, check in without a config, and so do node-cron 3 schedules with steps it reads differently from standard cron, like
*/2days. Tasks already wrapped byinstrumentNodeCronare skipped, so using both doesn't send duplicate check-ins.