feat: add isExecuting() to observe manual execute() runs - #612
Open
sarmah-rup wants to merge 1 commit into
Open
Conversation
Copy link
Copy Markdown
Sorry, something went wrong.
Copy link
Copy Markdown
Member
|
hello @sarmah-rup thank for the PR, holding on it because the behavior was intentional. |
Sorry, something went wrong.
getStatus()/isBusy() intentionally reflect only the scheduled lifecycle state: a manual execute() runs the task function outside the state machine by design (it can run on a stopped task, never counts toward maxExecutions, etc). That means a manually invoked run was invisible to any 'is a run in progress right now' check. Add isExecuting(), a separate signal that returns true while any run (scheduled or invoked) is actually in flight, without touching the lifecycle state. The inline task tracks an in-flight counter; the background task exposes its existing 'executing' flag over IPC. Use it for graceful shutdown (wait until no run is in flight) or overlap checks that must also see manual runs. Closes node-cron#611
sarmah-rup
force-pushed
the
fix/track-invoked-runs
branch
from
c3b6e8b to
ae20a8a
Compare
July 20, 2026 17:16
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
2 participants
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.
Problem
getStatus() / isBusy() only reflect the scheduled lifecycle, so a run started via execute() (reason 'invoked') is invisible: mid-run getStatus() reports idle and isBusy() returns false. There's no way to poll "is any run in progress right now", which the use case in #611 needs (graceful shutdown that waits for in-flight work; not overlapping a manual run with a scheduled one).
Approach
Following the discussion in #611: execute() deliberately runs outside the state machine (it can run on a stopped task, never counts toward maxExecutions, etc.), so this does not touch getStatus() / isBusy(). Instead it adds a separate signal, as suggested:
The inline task tracks a small in-flight counter (incremented for every run, so overlapping runs are handled); the background task already keeps an internal executing flag synced over IPC, so it just exposes it. The lifecycle state is untouched: it still flips only for scheduled runs.
Tests
Full suite green (757 tests), 100% coverage on the touched files.
Closes #611