Skip to content

fix(cli): prevent hot reload server from pinning a CPU core (#816)#825

Open
lewinpauli wants to merge 1 commit into
schultek:mainfrom
lewinpauli:fix/hot-reload-cpu-busyloop
Open

fix(cli): prevent hot reload server from pinning a CPU core (#816)#825
lewinpauli wants to merge 1 commit into
schultek:mainfrom
lewinpauli:fix/hot-reload-cpu-busyloop

Conversation

@lewinpauli

Copy link
Copy Markdown

Description

jaspr serve pins a CPU core at 100% even while completely idle (#816).

The generated server_target.dart created the HotReloader with
debounceInterval: Duration.zero. The hotreloader package reuses that value
as the pollingDelay for any watcher that falls back to polling — notably for
watch paths that don't exist, such as an unused bin/ or test/ directory.
With a zero delay this becomes a tight busy loop that pins a CPU core, on every
platform. Most Jaspr projects have neither bin/ nor test/, so two such
watchers spin indefinitely.

This PR:

  • Uses a non-zero debounceInterval (200ms) in the generated entrypoint, so any
    polling fallback no longer busy-loops. This alone fixes the reported issue.
  • (Optional optimization) Additionally passes excludedPaths for bin/test
    when those folders are absent, so no polling watcher is created for them in the
    first place. Not strictly required once the above is in place — happy to drop
    it if you prefer a more minimal change.

Type of Change

  • 🛠️ Bug fix

Ready Checklist

  • I've read the Contribution Guide.
  • In case this PR changes one of the core packages, I've modified the respective CHANGELOG.md file using the semantic_changelog format.
  • I updated/added relevant documentation (doc comments with ///).
  • I added myself to the AUTHORS file (optional, if you want to).

…#816)

The generated server_target.dart created the HotReloader with
`debounceInterval: Duration.zero`. hotreloader reuses that value as the
`pollingDelay` for any watcher that falls back to polling — notably for
paths that don't exist, such as an unused `bin/` or `test/` directory.
With a zero delay this turns into a tight busy loop that pins a CPU core
to 100% even while idle, on every platform.

- Use a non-zero `debounceInterval` (200ms) so any polling fallback no
  longer busy-loops. This alone fixes the reported issue.
- Additionally pass `excludedPaths` for `bin`/`test` when those folders
  are absent, so no polling watcher is created for them in the first
  place.
@lewinpauli lewinpauli requested a review from schultek as a code owner June 29, 2026 10:24
@docs-page

docs-page Bot commented Jun 29, 2026

Copy link
Copy Markdown

To preview the documentation for this pull request, visit the following URL:

docs.jaspr.site/~825

Documentation is deployed and generated using docs.page

@github-actions

Copy link
Copy Markdown

Package Version Report

The following packages have been updated:
jaspr_test : 0.23.1 -> 0.23.2
jaspr : 0.23.1 -> 0.23.2
jaspr_builder : 0.23.1 -> 0.23.2
jaspr_cli : 0.23.1 -> 0.23.2

@schultek

schultek commented Jul 2, 2026

Copy link
Copy Markdown
Owner

Thanks for this fix.

Regarding excludePaths, the hotreloader docs say:

[excludedPaths] are always relative to the project's root directory. If the project is a pub workspace, the bin folder of the package will be located in the packages/<package> folder. That means it should be specified like packages/<package>/bin in [excludedPaths], where <package> is the name of the package where the HotReloader is created. If the project consists of a single package, the bin directory lies in the project's root folder and should be specified like bin in [excludedPaths].

So we would have to have a more complex setup for these paths to detect if jaspr is run in a workspace or not.

To avoid that let's just drop the excluded paths, since you said the debounce duration already fixes it. I'm also ok with setting this higher, e.g. 1 second which is the default value.

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