Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trunk serve can get caught in a build loop when compiling web workers #422

Closed
gilescope opened this issue Aug 27, 2022 · 10 comments · Fixed by #593
Closed

trunk serve can get caught in a build loop when compiling web workers #422

gilescope opened this issue Aug 27, 2022 · 10 comments · Fixed by #593
Labels
bug Something isn't working cli Trunk CLI application investigate More investigation is needed

Comments

@gilescope
Copy link
Contributor

If I make a change and trunk serve detects it and rebuilds my code and the web worker, it occasionally will go into a loop. I guess the building of one can sometimes trigger the rebuilding of the other and so on and so on... a restart fixes it and then it's well behaved for a while. Does the webworker generat a js file that re-triggers the build or something?

@simbleau
Copy link
Member

simbleau commented Aug 27, 2022

I've noticed this happens when I sometimes git pull or bring in new files. Still trying to find the root cause.

My theory is that (without looking at the code) It probably rebuilds once per new file introduced, so if a lot of new code gets introduced at once, it may be re-compiling for a while, and seem like an infinite loop.

@simbleau simbleau added bug Something isn't working investigate More investigation is needed cli Trunk CLI application labels Aug 27, 2022
@Mubelotix
Copy link

This happens to me all the time, trunk spends 100% of the time rebuilding useless stuff

@DimitriTimoz
Copy link

I'm also affected it's also maybe a duplicate of #382

@gilescope
Copy link
Contributor Author

gilescope commented Aug 27, 2022 via email

@webbertakken
Copy link

It probably rebuilds once per new file introduced, so if a lot of new code gets introduced at once, it may be re-compiling f

Having witnessed this quite a few times by now, this seems to be accurate.

Another example is that when using cargo clippy as an external linter in WebStorm, it'll compile 2 to 3 times more than normal when saving, because the file actually changes multiple times.

It looks like each change queues a rebuild, where for most cases it's probably fine to just do the current and last rebuild.

@thedodd
Copy link
Member

thedodd commented Nov 28, 2022

@gilescope that's it ... we're removing support for web workers in Trunk! Too much maintenance overhead!

JK JK, hopefully we can get this issue pinned down soon.

@thedodd
Copy link
Member

thedodd commented Nov 28, 2022

@gilescope @webbertakken @Mubelotix if folks don't mind running trunk with verbose logging, it will tell you where the changes were detected. EG: trunk -v serve

So, if you are certain that this is not a config issue, then this is probably the next best thing to look into. Find out which files are changing which are causing trunk to re-build, then we can determine the root cause.

You should see a log line similar to:

2022-11-28T17:11:25.541456Z DEBUG change detected in "{base_path}/src/bin/worker.rs"

@rlane
Copy link

rlane commented Mar 18, 2023

This happens to me often when switching branches. When running trunk with the -v flag I see it's doing a rebuild for each changed file. This is with trunk 0.16.0.

@ctron
Copy link
Collaborator

ctron commented Aug 10, 2023

I guess this is another variation which might be fixed by either #516 or #569

@thedodd
Copy link
Member

thedodd commented Aug 21, 2023

Ok, looks like this is a known issue which folks are seeing: notify-rs/notify#259

As it turns out, this is not due to a library we are using, but comes from std::fs::copy, which I have verified. I don't know how broadly this applies across platforms; however, it is broad enough that it has impacted a lot of folks.

I've implemented a solution to address this. A cooldown period following a build. All events will be ignored following a build completion for the cooldown period, which I will hardcode to 1s for now. That should be enough without impacting the development flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working cli Trunk CLI application investigate More investigation is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants