Skip to main content

Class: ScheduleWatcher

Defined in: watchers/schedule.watcher.ts:73

Implements​

  • OnModuleInit
  • OnApplicationBootstrap
  • OnModuleDestroy

Constructors​

Constructor​

new ScheduleWatcher(collector, discoveryService, nestlensConfig): ScheduleWatcher

Defined in: watchers/schedule.watcher.ts:87

Parameters​

collector​

CollectorService

discoveryService​

DiscoveryService

nestlensConfig​

NestLensConfig

Returns​

ScheduleWatcher

Methods​

onApplicationBootstrap()​

onApplicationBootstrap(): void

Defined in: watchers/schedule.watcher.ts:97

Returns​

void

Implementation of​

OnApplicationBootstrap.onApplicationBootstrap

onModuleDestroy()​

onModuleDestroy(): void

Defined in: watchers/schedule.watcher.ts:311

Puts the registry and every job back the way they were.

The registry is a singleton the application owns, and the cron jobs on it outlive the module: without this a closed application goes on ticking through a watcher whose collector is gone, and a process that builds the module more than once against the same registry — tests, nest start --hmr — wraps each round on top of the last. Measured at three lifecycles: one tick, six entries.

Returns​

void

Implementation of​

OnModuleDestroy.onModuleDestroy

onModuleInit()​

onModuleInit(): void

Defined in: watchers/schedule.watcher.ts:141

Tracks @Interval and @Timeout, which nothing was doing.

Only @Cron was ever recorded. The two others were reached for through the registry, which holds the timer handles — there is no callback on a Timeout object to wrap — so the watcher logged "registered but cannot be wrapped" and moved on. The payload has declared interval and timeout fields the whole time, documented as "reserved, not currently populated", and the watcher's own page shows both decorators in its examples.

The callback does exist one layer up. @nestjs/schedule keeps every scheduled method on its SchedulerOrchestrator and turns them into timers in mountIntervals and mountTimeouts, which run in its onApplicationBootstrap. Replacing those two methods puts a wrapper around each target before setInterval ever sees it.

This runs in onModuleInit on purpose: Nest completes every module's onModuleInit before it starts any onApplicationBootstrap, so being early enough is a guarantee rather than a question of module order — which is what made the cron half of this watcher record nothing on NestJS 9 and 10 until it was moved.

Returns​

void

Implementation of​

OnModuleInit.onModuleInit