Skip to content

feat(job-options): warn on suspiciously-large removeOn*.age values (#3540) - #4059

Open
maruthang wants to merge 2 commits into
taskforcesh:masterfrom
maruthang:fix/issue-3540-removeOn-age-validation
Open

feat(job-options): warn on suspiciously-large removeOn*.age values (#3540)#4059
maruthang wants to merge 2 commits into
taskforcesh:masterfrom
maruthang:fix/issue-3540-removeOn-age-validation

Conversation

@maruthang

Copy link
Copy Markdown
Contributor

Why

Closes #3540. The reporter observed jobs being unexpectedly auto-removed with no logs, with the most likely root cause being a unit-confusion bug: removeOnComplete.age and removeOnFail.age are documented in seconds, but it's easy to pass a value computed in milliseconds (e.g. 7 * 24 * 60 * 60 * 1000 instead of 7 * 24 * 60 * 60). Treated as seconds, those values become decades or centuries — the user thinks "retention 7 days", actually configures "retention ~19 years", and is surprised when behavior diverges from expectations. The current code silently accepts them.

How

  • Added validateKeepJobsAge in src/utils/index.ts and exported MAX_REASONABLE_KEEP_JOBS_AGE_SECONDS = 315_360_000 (10 years). When age exceeds the threshold, a non-throwing console.warn is emitted suggesting the user may have confused milliseconds with seconds and showing the equivalent value in days/years.
  • Wired the validation into:
    • Queue constructor (defaultJobOptions)
    • Worker constructor (removeOnComplete / removeOnFail)
    • Queue#addJob merged opts
  • Warnings deduped per (context, value) so noisy callers see each suspicious value once.
  • Updated JSDoc on KeepJobs.age, DefaultJobOptions.removeOn*, and WorkerOptions.removeOn* to make the seconds unit explicit and include a worked example: 7 * 24 * 60 * 60.

Additional Notes

  • Non-breaking. Existing valid configs are untouched; only suspicious values trigger a warning.
  • 10-year threshold deliberately leaves headroom for legitimate multi-year retention while still flagging the obvious unit-confusion cases (7 days as ms ≈ 19 yr, 30 days as ms ≈ 82 yr — both caught).
  • Tests: new tests/validate_keep_jobs_age.test.ts (10 unit tests, all passing); tests/clean.test.ts (42 Redis-backed) all green — no regression in the option-parsing path.
  • yarn build and yarn lint clean.

…askforcesh#3540)

Issue taskforcesh#3540 reports jobs being auto-removed without explanation. The
reporter (and others in similar reports) configured retention with
values such as `7 * 24 * 60 * 60 * 1000`, mistakenly assuming the
`age` field is expressed in milliseconds. BullMQ interprets it as
seconds, leading to nonsensical retention windows of ~19 years and
masking the original intent.

Add a non-throwing runtime warning emitted from Queue and Worker
construction (and from `Queue#add`'s merged options) when
`removeOnComplete.age` or `removeOnFail.age` exceeds 10 years (the
documented `MAX_REASONABLE_KEEP_JOBS_AGE_SECONDS`). The warning is
deduplicated per (context, value) so noisy applications only see it
once. Also tighten the JSDoc on `KeepJobs.age` and the surrounding
option fields to make the seconds-vs-milliseconds distinction
explicit, with worked examples for 7-day and 30-day retention.
…moveOn-age-validation

# Conflicts:
#	src/classes/queue.ts
#	src/classes/worker.ts
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.

[Bug]: Jobs gets auto removed from the queue and no logs to found

1 participant