Repository navigation
Conversation
Draft
1 of 3 tasks
`Sentry.cron.instrumentBullMQWorker(worker)` sends check-ins for every job the worker runs from a job scheduler, using the scheduler id as the monitor slug and its `pattern` or `every` as the monitor schedule. Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
wedamija
force-pushed
the
danf/bullmq-cron-monitors
branch
from
October 20, 2026 00:51
dd87bd3 to
b7b621e
Compare
Co-Authored-By: Claude <noreply@anthropic.com>
wedamija
changed the title
Co-Authored-By: Claude <noreply@anthropic.com>
…onitors-merge # Conflicts: # pnpm-lock.yaml
Contributor
size-limit report 📦Compared: de48a2b (PR test merge using danf/shared-cron-converter at 28da7c9) Against: c491307 (danf/shared-cron-converter) · base run #65764
|
Contributor
Optional E2E testsSome optional checks were not successful. They do not block the merge. 4 not successful, 51 successful. See the run.
Successful checks
|
# Conflicts: # dev-packages/node-integration-tests/package.json # pnpm-lock.yaml
The BullMQ tracing suite from develop also binds 6384.
With BullMQTelemetry, the worker emits `active` before the job's process span starts, so the in_progress check-in linked to the previous job's trace. Sentry keeps that trace for the check-in. Send it from the processor instead, and add an integration test that runs a job scheduler with both enabled.
instrumentBullMQWorker only monitors job schedulers whose schedule Sentry can represent.
…onitors # Conflicts: # packages/node/src/cron/index.ts
BullMQ emits `failed` for every attempt, so a retried job sent an error check-in and then opened a second in_progress. The check-in id now comes from the job, so retries and reruns of stalled jobs update the first attempt's check-in, even on another worker, and only the last failure sends an error. Also skips `pattern` schedules when the worker has a custom repeat strategy. Co-Authored-By: Claude <noreply@anthropic.com>
…onitors # Conflicts: # CHANGELOG.md
… danf/bullmq-cron-monitors # Conflicts: # CHANGELOG.md
BullMQ patterns go through `getCronMonitorConfig` with the `cron-parser` dialect, like `node-schedule`. The monitor slug is `<queue>-<scheduler id>`, since scheduler ids are only unique within a queue. Co-Authored-By: Claude <noreply@anthropic.com>
… danf/bullmq-cron-monitors
…egration Adding the integration is the opt-in, and it monitors every BullMQ Worker without a per-worker call. It lives in server-utils next to the other cron integrations and hooks the Worker constructor through the runtime diagnostics-channel injection, in CJS and ESM. BullMQ is only in the runtime instrumentation list. In the bundler list, the plugins would force it into bundles, where it can't find the files it starts sandboxed processors from. Co-Authored-By: Claude <noreply@anthropic.com>
wedamija
changed the title
Co-Authored-By: Claude <noreply@anthropic.com>
Frameworks pass this list to their keep-external option, so BullMQ loads through Node's loader, where the runtime hook instruments it. Co-Authored-By: Claude <noreply@anthropic.com>
`bun run` can't inject the worker channel, and the bundler plugins don't instrument BullMQ, so the integration would never send a check-in on Bun. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
BullMQ 6 is npm latest and uses cron-parser 5, which reads the converted expressions like cron-parser 4 (fuzzed against cronsim) but ignores `utc` and `nthDayOfWeek`. BullMQ 5 reads `nthDayOfWeek` like `#n`, so it's sent that way when that's exact and skipped otherwise. Legacy repeatable jobs are told apart from job schedulers by `repeat.key` or by their key matching the name and repeat options, so scheduler ids that look like hashes or have colons are monitored. The reason a scheduler isn't monitored is logged once. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… danf/bullmq-cron-monitors
…iber Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ribers get unknown Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…common key hashes A queue's repeatKeyHashAlgorithm isn't reachable from the worker, so legacy keys hashed with md5, sha1, sha256 or sha512 are recognized too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…s logging Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…meout Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.
This adds
bullmqJobSchedulerIntegration, which sends check-ins for the jobs every BullMQ worker (5.16.0 to 6.x) runs from a job scheduler, with<queue>-<scheduler id>as the monitor slug and the scheduler'spatternoreveryas the schedule. Adding the integration is the opt-in, so no per-worker call is needed; schedulers Crons can't express aren't monitored, and a retried job keeps one check-in.BullMQ is only in the runtime instrumentation list: the bundler plugins force listed packages into the bundle, where BullMQ can't find the files it starts sandboxed processors from. That also means
bun runcan't instrument it, so@sentry/bundoesn't export the integration.Stacked on #25918.
Docs: getsentry/sentry-docs#20053