Skip to content

Add scheduler alarm diagnostics - #240

Merged
kentcdodds merged 7 commits into
mainfrom
cursor/scheduler-alarm-diagnostics-eb7d
Apr 21, 2026
Merged

kentcdodds merged 7 commits into
mainfrom
cursor/scheduler-alarm-diagnostics-eb7d

Conversation

@kentcdodds

@kentcdodds kentcdodds commented Apr 20, 2026 •

Copy link
Copy Markdown
Owner

Summary

  • add focused scheduler diagnostics for one-off and recurring jobs across job creation, alarm sync requests, JobManager alarm decisions, and alarm firing
  • merge the latest main branch changes, preserving new job inspection/debug capabilities alongside the scheduler diagnostics
  • address valid AI review feedback by treating reschedule failures as failed scheduler outcomes, truncating logged error strings, fixing timestamp fallback before serialization, normalizing scheduler event tokens, and removing a duplicate post-create alarm sync now handled by createJob
  • add targeted node coverage for processDueJobs, JobManager alarm logging behavior/error branches, scheduler log sanitization, and the new alarm-state helper from main

Testing

  • npx vitest --config vitest.node.config.ts "packages/worker/src/jobs/manager-do.node.test.ts" "packages/worker/src/jobs/service.node.test.ts" "packages/worker/src/mcp/capabilities/jobs/job-schedule.node.test.ts"
  • npx vitest --config vitest.node.config.ts "packages/worker/src/jobs/process-due-jobs.node.test.ts" "packages/worker/src/jobs/scheduler-logging.node.test.ts" "packages/worker/src/jobs/manager-do.node.test.ts" "packages/worker/src/mcp/capabilities/jobs/job-schedule.node.test.ts"
  • npm run typecheck

Walkthrough

scheduler_diagnostics_validation.mp4

Open in Web Open in Cursor 

Summary by CodeRabbit

  • New Features

    • Richer job-scheduler telemetry: structured events for alarms, runs, resyncs, and capped per-job outcome summaries; run operations now return detailed counts and per-job outcome logs.
  • Bug Fixes

    • Improved error reporting and resilience for alarm syncs, job runs, and rescheduling with clearer failure fields and safer logging.
  • Tests

    • Expanded test suite covering scheduler logging, alarm lifecycle, and due-job processing (including outcome/truncation behaviors).

@coderabbitai

coderabbitai Bot commented Apr 20, 2026 •

Copy link
Copy Markdown
📝 Walkthrough

Walkthrough

Adds structured scheduler logging and error normalization across job creation, Durable Object alarm lifecycle, RPC-based alarm sync, job execution, and outcome reporting; exports JobManagerBase and expands processDueJobs/runDueJobsForUser results to include per-job outcome aggregates.

Changes

Cohort / File(s) Summary
Scheduler Logging Infrastructure
packages/worker/src/jobs/scheduler-logging.ts, packages/worker/src/jobs/scheduler-logging.node.test.ts
New module exposing types and helpers (SchedulerJobOutcomeLog, schedulerErrorFields, summarizeSchedulerJobOutcomes, logJobSchedulerEvent, logJobSchedulerError) that sanitize, truncate, timestamp, and emit JSON scheduler events; tests validate truncation, timestamp presence, and outcome summarization.
Job Manager Durable Object
packages/worker/src/jobs/manager-do.ts, packages/worker/src/jobs/manager-do.node.test.ts
Made JobManagerBase exported; syncAlarm and alarm now emit structured scheduler events/errors, wrap key operations in try/catch, accept optional alarmInfo (retry metadata) on alarm, and include comprehensive tests for alarm arming, firing, processing, and resync behavior.
Manager RPC Client
packages/worker/src/jobs/manager-client.ts
syncJobManagerAlarm now logs structured events: skips with sync_alarm_skipped_missing_binding when binding missing, logs sync_alarm_requested/sync_alarm_completed on success (including nextRunAt and reason), and logs sync_alarm_request_failed with schedulerErrorFields on RPC errors; preserves original error propagation.
Job Processing & Service
packages/worker/src/jobs/process-due-jobs.ts, packages/worker/src/jobs/process-due-jobs.node.test.ts, packages/worker/src/jobs/service.ts
ProcessDueJobsResult exported and extended with successCount, errorCount, and jobOutcomes; processDueJobs records per-job outcomes, handles reschedule failures (disables job, records rescheduleError), and tests updated to assert aggregated counts/outcomes; runDueJobsForUser returns structured counts/outcomes and emits an empty-run event when no due jobs.
Job Creation Flow
packages/worker/src/mcp/capabilities/jobs/shared.ts
After successful createJob, emits job-created event; moves syncJobManagerAlarm call into try/catch and logs job-manager-sync-after-create-failed with schedulerErrorFields on failure before rethrowing.
Minor formatting / imports
packages/worker/src/jobs/service.ts, other small edits
Cosmetic import/type formatting and argument reflow changes; no behavioral change beyond logging/return-shape updates described above.

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant ManagerRPC
  participant JobManagerDO
  participant SchedulerLog

  Client->>ManagerRPC: syncJobManagerAlarm(env,userId)
  Note right of ManagerRPC: logs sync_alarm_requested
  ManagerRPC->>JobManagerDO: rpc.syncAlarm(env,userId)
  JobManagerDO->>SchedulerLog: log sync_alarm (armed/no-runnable/reason)
  JobManagerDO-->>ManagerRPC: { ok, nextRunAt }
  ManagerRPC->>SchedulerLog: log sync_alarm_completed (userId,nextRunAt,reason)
  ManagerRPC-->>Client: { ok, nextRunAt }

  alt RPC unavailable
    ManagerRPC->>SchedulerLog: log sync_alarm_skipped_missing_binding (userId,reason)
    ManagerRPC-->>Client: { ok: true, nextRunAt: null }
  end

  alt error during RPC
    ManagerRPC->>SchedulerLog: log sync_alarm_request_failed (schedulerErrorFields)
    ManagerRPC-->>Client: throw error
  end
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

Poem

🐇 I hopped through alarms and logs so bright,

timestamps dancing in the night,
each job outcome neatly penned—
a rabbit's log from start to end,
hopping errors back to right.

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title 'Add scheduler alarm diagnostics' directly summarizes the main change: adding diagnostics logging throughout the scheduler alarm system (sync requests, firing, execution summaries, and error tracking).
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch cursor/scheduler-alarm-diagnostics-eb7d

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@kentcdodds
kentcdodds marked this pull request as ready for review April 20, 2026 22:08
@github-actions

github-actions Bot commented Apr 20, 2026 •

Copy link
Copy Markdown
Contributor

🔎 Preview deployed: https://kody-pr-240.kentcdodds.workers.dev

Worker: kody-pr-240
D1: kody-pr-240-db
KV: kody-pr-240-oauth-kv

Mocks:

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/worker/src/jobs/process-due-jobs.ts`:
- Around line 85-101: The current catch block treats a reschedule failure as a
success because jobOutcomes uses outcome.execution.ok; change the job outcome
logic so reschedule failures are counted as failures: compute a finalOutcome
that is 'failure' if rescheduleError is truthy (even when outcome.execution.ok
is true) and use that finalOutcome when pushing into jobOutcomes; also ensure
applyExecutionOutcome/update logic still disables the job and records
lastRunError (keep the existing applyExecutionOutcome call that sets
enabled:false and lastRunError) so the stored job reflects the reschedule
failure while the jobOutcomes summary reflects a failure.

In `@packages/worker/src/jobs/scheduler-logging.ts`:
- Around line 55-87: The logs currently serialize the full
JobSchedulerLogPayload in writeSchedulerLog (used by
logJobSchedulerEvent/logJobSchedulerError) which allows unbounded
user/job-provided strings; before JSON.stringify, centrally truncate/sanitize
input.errorMessage and each entry in input.jobOutcomes[*] (specifically fields
named error and rescheduleError) to a fixed max length (e.g.
MAX_LOG_STRING_LENGTH) and replace with a capped version (or "[TRUNCATED]") so
summarizeSchedulerJobOutcomes still controls count while writeSchedulerLog
enforces per-field size limits and avoids oversized or sensitive payloads.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: d4791203-c12d-477a-8f42-e4bffbad0b15

📥 Commits

Reviewing files that changed from the base of the PR and between 6e650bf and de0878c.

📒 Files selected for processing (8)
  • packages/worker/src/jobs/manager-client.ts
  • packages/worker/src/jobs/manager-do.node.test.ts
  • packages/worker/src/jobs/manager-do.ts
  • packages/worker/src/jobs/process-due-jobs.node.test.ts
  • packages/worker/src/jobs/process-due-jobs.ts
  • packages/worker/src/jobs/scheduler-logging.ts
  • packages/worker/src/jobs/service.ts
  • packages/worker/src/mcp/capabilities/jobs/shared.ts

Comment thread packages/worker/src/jobs/process-due-jobs.ts
Comment thread packages/worker/src/jobs/scheduler-logging.ts
Comment thread packages/worker/src/jobs/scheduler-logging.ts
cursoragent and others added 3 commits April 21, 2026 01:40
Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
@cursor
cursor Bot force-pushed the cursor/scheduler-alarm-diagnostics-eb7d branch from 79ec26c to 8060d22 Compare April 21, 2026 01:42

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

🧹 Nitpick comments (5)
packages/worker/src/jobs/scheduler-logging.node.test.ts (1)

37-130: Console override is not isolated across concurrent tests.

Each test stubs console.error directly (lines 41–44, 68–70, 111–113) and restores it in finally. If Vitest ever runs tests in this file concurrently (e.g., test.concurrent or a future concurrency flip), these stubs will clobber each other and capture the wrong payload. Consider using vi.spyOn(console, 'error').mockImplementation(...) inside a beforeEach/afterEach pair, or wrap each stub in a helper that returns a per-test capture closure — this also removes the need for the as typeof console.error casts.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@packages/worker/src/jobs/scheduler-logging.node.test.ts` around lines 37 -
130, Tests directly reassign console.error which can race between concurrent
tests; change the stubs to per-test spies using vi.spyOn(console,
'error').mockImplementation(...) and restore them in afterEach (or use
beforeEach/afterEach) so each test (e.g., the tests calling logJobSchedulerError
in this file) gets an isolated mock and no global reassignment occurs; ensure
you capture the mock's calls (mock.calls) to get tag/json and call mockRestore()
in cleanup.
packages/worker/src/jobs/manager-do.ts (1)

93-98: alarm_fired emitted before the try/catch wrapping runDueJobsForUser.

If logJobSchedulerEvent itself ever throws (e.g. JSON.stringify on a cyclic payload) on line 93 or on line 85, the alarm handler propagates that error to the Durable Object runtime without resetting the alarm — you'll lose the fire entirely. Given the current payload fields are all primitives, this is very unlikely in practice, but it's worth being aware that all logging calls in this file are outside the top-level error boundary. No change required if you're confident the payloads stay serialization-safe.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@packages/worker/src/jobs/manager-do.ts` around lines 93 - 98, The
logJobSchedulerEvent calls (e.g., the call emitting 'alarm_fired' using
alarmInfo.retryCount/isRetry) are currently executed outside the top-level
try/catch that wraps runDueJobsForUser, so any serialization error could
propagate and lose the alarm; wrap each logJobSchedulerEvent invocation in a
defensive try/catch (or use a small safeLog wrapper) so logging failures are
swallowed or routed to a fallback logger and do not throw, and/or move the
logJobSchedulerEvent calls inside the existing try/catch that surrounds
runDueJobsForUser to ensure the Durable Object alarm is always reset even if
logging fails.
packages/worker/src/jobs/manager-do.node.test.ts (2)

66-100: createState treats null userId as a valid stored value.

userId?: string | null with currentAlarmAt=null and the guard if (userId !== undefined) persistedEntries.set('user-id', userId) (line 74) means passing { userId: null } persists 'user-id' → null, which then fails if (!userId) inside alarm() and exercises the missing-user branch — but no test uses it, and the type allows null without any callsite actually passing it. Either tighten the type to userId?: string (so tests always persist a real id) or add the missing-user test that would justify the null branch.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@packages/worker/src/jobs/manager-do.node.test.ts` around lines 66 - 100,
createState currently allows userId: string | null and then stores null as
'user-id', which incorrectly exercises the missing-user branch in alarm();
change the createState signature to userId?: string (remove | null) and ensure
persistedEntries only gets set when userId is not undefined (keep the existing
guard), so tests always persist a real id and the null branch is not
accidentally exercised; update the createState parameter type and any callsites
in the test file that pass null to instead omit the property or pass a real
string.

102-240: Test coverage gap: error paths and missing-userId branch are not exercised.

The suite covers only the happy paths of syncAlarm (with and without a next runnable job) and of alarm(). None of the new scheduler error branches introduced in this PR are covered:

  • sync_alarm_failed — triggered when getNextRunnableJob/setAlarm/deleteAlarm throws.
  • alarm_run_due_jobs_failed — triggered when runDueJobsForUser rejects.
  • alarm_resync_failed — triggered when the post-execution syncAlarm rejects.
  • alarm_fired with reason: 'missing-user-id' — triggered when storage has no persisted user-id.
  • runNow path (still catches sync errors via console.error).

Since the primary value of this PR is observability of failure modes, adding at least one test per error branch (asserting logJobSchedulerError is called with the right event and errorMessage) would lock in the contract the dashboards will rely on.

Want me to draft tests for the three error events and the missing-userId branch?

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@packages/worker/src/jobs/manager-do.node.test.ts` around lines 102 - 240, Add
tests to cover the error branches introduced in JobManagerBase: simulate
failures in getNextRunnableJob/setAlarm/deleteAlarm to assert syncAlarm emits a
logJobSchedulerError with event 'sync_alarm_failed' and the errorMessage;
simulate runDueJobsForUser rejecting to assert alarm emits
'alarm_run_due_jobs_failed'; simulate the post-execution syncAlarm rejecting to
assert alarm emits 'alarm_resync_failed'; add a test where persistedEntries
lacks 'user-id' to exercise alarm logging 'alarm_fired' with reason
'missing-user-id'; for each test ensure you mock the corresponding module
function (getNextRunnableJob, setAlarm, deleteAlarm, runDueJobsForUser, and
JobManagerBase.syncAlarm as needed) and assert mockModule.logJobSchedulerError
was called with the correct event and errorMessage and that other success-path
logs are not relied upon.
packages/worker/src/jobs/service.ts (1)

1017-1025: O(n·m) lookup while persisting due-job results.

dueRows.find(...) is called inside the for loop for every saved job (and similarly on line 1008 inside executeJob). For a handful of due jobs this is fine, but if the batch ever grows, this becomes quadratic with no guard. Consider building a Map<jobId, dueRow> once before processDueJobs and reusing it for both the executor closure and the save/delete loops.

Proposed refactor
+	const dueRowById = new Map(dueRows.map((row) => [row.record.id, row] as const))
 	const result = await processDueJobs({
 		jobs: dueRows.map((row) => row.record),
 		now,
 		executeJob: async (job) => {
-			const row = dueRows.find((candidate) => candidate.record.id === job.id)
+			const row = dueRowById.get(job.id)
 			const callerContext = row?.callerContext ?? null
 			return executeJobOnce({ env: input.env, job, callerContext })
 		},
 	})
 	for (const job of result.saveJobs) {
-		const row = dueRows.find((candidate) => candidate.record.id === job.id)
+		const row = dueRowById.get(job.id)
 		await updateJobRow({
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@packages/worker/src/jobs/service.ts` around lines 1017 - 1025, The code
currently does repeated O(n·m) lookups using dueRows.find(...) for each job;
create a Map keyed by job id (e.g., const dueRowById = new Map(dueRows.map(r =>
[r.record.id, r]))) once at the start of processDueJobs and replace all
dueRows.find(...) usages (including in the executor passed to executeJob and the
loop over result.saveJobs) with dueRowById.get(job.id); preserve the existing
fallback for callerContextJson (row?.callerContextJson ?? 'null') when reading
from the map.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/worker/src/jobs/manager-client.ts`:
- Around line 41-75: The logs/events use mixed case conventions; standardize to
snake_case across related files so consumers see one format. Update all emitted
event and reason strings to snake_case (e.g., in manager-do.ts change
'no-runnable-job' -> 'no_runnable_job', 'alarm-armed' -> 'alarm_armed', etc.) to
match existing values emitted by manager-client.ts (which emits
'sync_alarm_skipped_missing_binding', 'no_runnable_job_found',
'alarm_state_updated'), and ensure callers/emitters such as
logJobSchedulerEvent, logJobSchedulerError, rpc.syncAlarm, schedulerErrorFields,
and any service handlers (e.g., run_due_jobs.empty in service.ts) use the same
snake_case tokens so logging is consistent across the codebase.

In `@packages/worker/src/jobs/manager-do.node.test.ts`:
- Around line 44-53: Replace the inline typeof import(...) type annotation in
the vi.mock callback with a top-level type import: add a top-level "import type"
for the module (e.g., import type * as SchedulerLoggingType from
'./scheduler-logging.ts') and then change the generic on importOriginal to use
that type (importOriginal<typeof SchedulerLoggingType>); keep the existing
mockModule forwarding for logJobSchedulerEvent and logJobSchedulerError and
ensure the vi.mock callback signature still uses importOriginal typed by the new
top-level type.

In `@packages/worker/src/jobs/manager-do.ts`:
- Around line 104-112: The log emitted by logJobSchedulerEvent in manager-do
uses inconsistent event and reason strings compared to service.ts; normalize
them to the same convention by changing the event and reason values used in the
logJobSchedulerEvent call (refer to logJobSchedulerEvent and the reason
conditional producing 'no-due-jobs' / 'processed-due-jobs') to match the
canonical names used in service.ts (e.g., use 'run_due_jobs.empty' and
'no_due_jobs_found' or whatever service.ts uses) so all scheduler logging (event
and reason) is consistent across manager-do and service.ts.
- Around line 22-76: The inner catch in syncAlarm is emitting sync_alarm_failed
and then rethrowing, causing duplicate error entries when callers (e.g.,
alarm()) also log; modify syncAlarm to accept a source discriminator (e.g.,
source: 'alarm' | 'rpc' | 'runNow') and include that source in the
sync_alarm_failed log payload instead of removing the log; update the
logJobSchedulerError call inside the catch in syncAlarm to add source, and
update all callers (alarm(), RPC entry, runNow path) to pass the appropriate
source when invoking syncAlarm so downstream logs can be de-duped by source.

In `@packages/worker/src/jobs/service.ts`:
- Around line 990-1003: The scheduler event emitted by logJobSchedulerEvent uses
dot notation and a mismatched reason; update the logJobSchedulerEvent call (the
object with keys event and reason) so both fields use the project's snake_case
convention to match other events (e.g., change event to run_due_jobs_empty and
reason to no_due_jobs) and/or reconcile the reason with the equivalent emission
in manager-do.ts (no-due-jobs) so the same underlying condition produces a
single searchable value across the codebase.

---

Nitpick comments:
In `@packages/worker/src/jobs/manager-do.node.test.ts`:
- Around line 66-100: createState currently allows userId: string | null and
then stores null as 'user-id', which incorrectly exercises the missing-user
branch in alarm(); change the createState signature to userId?: string (remove |
null) and ensure persistedEntries only gets set when userId is not undefined
(keep the existing guard), so tests always persist a real id and the null branch
is not accidentally exercised; update the createState parameter type and any
callsites in the test file that pass null to instead omit the property or pass a
real string.
- Around line 102-240: Add tests to cover the error branches introduced in
JobManagerBase: simulate failures in getNextRunnableJob/setAlarm/deleteAlarm to
assert syncAlarm emits a logJobSchedulerError with event 'sync_alarm_failed' and
the errorMessage; simulate runDueJobsForUser rejecting to assert alarm emits
'alarm_run_due_jobs_failed'; simulate the post-execution syncAlarm rejecting to
assert alarm emits 'alarm_resync_failed'; add a test where persistedEntries
lacks 'user-id' to exercise alarm logging 'alarm_fired' with reason
'missing-user-id'; for each test ensure you mock the corresponding module
function (getNextRunnableJob, setAlarm, deleteAlarm, runDueJobsForUser, and
JobManagerBase.syncAlarm as needed) and assert mockModule.logJobSchedulerError
was called with the correct event and errorMessage and that other success-path
logs are not relied upon.

In `@packages/worker/src/jobs/manager-do.ts`:
- Around line 93-98: The logJobSchedulerEvent calls (e.g., the call emitting
'alarm_fired' using alarmInfo.retryCount/isRetry) are currently executed outside
the top-level try/catch that wraps runDueJobsForUser, so any serialization error
could propagate and lose the alarm; wrap each logJobSchedulerEvent invocation in
a defensive try/catch (or use a small safeLog wrapper) so logging failures are
swallowed or routed to a fallback logger and do not throw, and/or move the
logJobSchedulerEvent calls inside the existing try/catch that surrounds
runDueJobsForUser to ensure the Durable Object alarm is always reset even if
logging fails.

In `@packages/worker/src/jobs/scheduler-logging.node.test.ts`:
- Around line 37-130: Tests directly reassign console.error which can race
between concurrent tests; change the stubs to per-test spies using
vi.spyOn(console, 'error').mockImplementation(...) and restore them in afterEach
(or use beforeEach/afterEach) so each test (e.g., the tests calling
logJobSchedulerError in this file) gets an isolated mock and no global
reassignment occurs; ensure you capture the mock's calls (mock.calls) to get
tag/json and call mockRestore() in cleanup.

In `@packages/worker/src/jobs/service.ts`:
- Around line 1017-1025: The code currently does repeated O(n·m) lookups using
dueRows.find(...) for each job; create a Map keyed by job id (e.g., const
dueRowById = new Map(dueRows.map(r => [r.record.id, r]))) once at the start of
processDueJobs and replace all dueRows.find(...) usages (including in the
executor passed to executeJob and the loop over result.saveJobs) with
dueRowById.get(job.id); preserve the existing fallback for callerContextJson
(row?.callerContextJson ?? 'null') when reading from the map.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: d26bf934-8615-43ef-8b35-c9faa9e19b5e

📥 Commits

Reviewing files that changed from the base of the PR and between de0878c and 8060d22.

📒 Files selected for processing (9)
  • packages/worker/src/jobs/manager-client.ts
  • packages/worker/src/jobs/manager-do.node.test.ts
  • packages/worker/src/jobs/manager-do.ts
  • packages/worker/src/jobs/process-due-jobs.node.test.ts
  • packages/worker/src/jobs/process-due-jobs.ts
  • packages/worker/src/jobs/scheduler-logging.node.test.ts
  • packages/worker/src/jobs/scheduler-logging.ts
  • packages/worker/src/jobs/service.ts
  • packages/worker/src/mcp/capabilities/jobs/shared.ts
🚧 Files skipped from review as they are similar to previous changes (4)
  • packages/worker/src/mcp/capabilities/jobs/shared.ts
  • packages/worker/src/jobs/process-due-jobs.node.test.ts
  • packages/worker/src/jobs/scheduler-logging.ts
  • packages/worker/src/jobs/process-due-jobs.ts

Comment thread packages/worker/src/jobs/manager-client.ts
Comment thread packages/worker/src/jobs/manager-do.node.test.ts
Comment thread packages/worker/src/jobs/manager-do.ts
Comment thread packages/worker/src/jobs/manager-do.ts
Comment thread packages/worker/src/jobs/service.ts
Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
Comment thread packages/worker/src/mcp/capabilities/jobs/shared.ts Outdated
cursoragent and others added 2 commits April 21, 2026 02:54
Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit dc2230e. Configure here.

Comment thread packages/worker/src/mcp/capabilities/jobs/shared.ts Outdated
Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
@kentcdodds
kentcdodds merged commit 849b60f into main Apr 21, 2026
9 checks passed
@kentcdodds
kentcdodds deleted the cursor/scheduler-alarm-diagnostics-eb7d branch April 21, 2026 03:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants