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.

Sign up for GitHub

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

Jump to bottom

File watching fails due to file not found on Ubuntu 22.04 LTS #8800

Open
1 task done
Byron opened this issue Jul 21, 2024 · 2 comments · May be fixed by #9406
Open
1 task done

File watching fails due to file not found on Ubuntu 22.04 LTS #8800

Byron opened this issue Jul 21, 2024 · 2 comments · May be fixed by #9406
Labels
kind: bug Something isn't working needs: triage New issues get this label. Remove it after triage

Comments

@Byron
Copy link

Byron commented Jul 21, 2024 •
edited
Loading

Verify canary release

  • I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

Please see steps to reproduce

What package manager are you using / does the bug impact?

pnpm

What operating system are you using?

Linux

Which canary version will you have in your reproduction?

2.0.7-canary.1

Describe the Bug

In my case, the failure is due to turbo trying to access a file (apparently) that was changed but also was removed immediately. Thus, the file access failed which seems to stop file watching entirely. turbo daemon clean is needed afterwards to be able to start a build at all (GitButler in this case). But no matter what, even with CARGO_BUILD_JOBS=1 to 'slow it down', it fails with something like…

WARN turborepo_filewatch: encountered error watching filesystem enumerating recursive watch: IO error for operation on /home/parallels/dev-local/gitbutler/target/debug/build/glib-sys-0003c7493fe374fe/rmetauJ5mbn: No such file or directory (os error 2)
2024-07-21T06:32:22.001687Z ERROR turborepo_lib::daemon::server: package changes stream closed: channel closed

…as obtained by turbo daemon logs.

This was tested with v2.0.9 by the way.

Expected Behavior

It shouldn't crash if a file is removed before it can access it.

To Reproduce

Prerequisites for the GitButler project

sudo apt update
sudo apt install libwebkit2gtk-4.0-dev \
    build-essential \
    curl \
    wget \
    file \
    libssl-dev \
    libgtk-3-dev \
    libayatana-appindicator3-dev \
    librsvg2-dev
curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh

Note that pnpm is also needed as runner.

git clone https://github.com/gitbutlerapp/gitbutler
cd gitbutler
pnpm install
pnpm tauri dev

The pnpm tauri dev call will try to launch turbo - the first time it straight up fails, the second time it runs for a while but fails later when Rust is compiling.

Additional context

Originally mentioned in #8006.
@Byron Byron added kind: bug Something isn't working needs: triage New issues get this label. Remove it after triage owned-by: turborepo labels Jul 21, 2024
This was referenced Jul 21, 2024
Closed
Open
@TrueBrain TrueBrain mentioned this issue Oct 5, 2024
Open
@JCMais
Copy link

JCMais commented Oct 26, 2024

having same issue, turborepo is not working properly on WSL due to this

@krlvi
Copy link

krlvi commented Nov 7, 2024

It seems like these issues are related: #8765 and #8491

Furthermore, it appears that this is a Linux specific issue originating here:

turborepo/crates/turborepo-filewatch/src/lib.rs

Line 275 in b65ff15

break 'outer;

(this function is feature flagged - the MacOS execution path is different)

I do wonder - is it really appropriate to exit the loop there? It appears that the file is gone before manually_add_recursive_watches (only used under windows) can begin watching.
It appears to me that matching for WatchError::WalkDir and continuing the loop would be correct.

krlvi added a commit to gitbutlerapp/turborepo that referenced this issue Nov 7, 2024
@krlvi
fix(filewatcher): handle removed directories vercel#8800
2192491 
When setting up manual recursive watching on folders (as is the case under Linux),
the watching thread should not exit if a directory no longer exists.
This is likely to occur within build output directories and it should
not be the cause for interrupting the daemon.
@krlvi krlvi linked a pull request Nov 7, 2024 that will close this issue
Open
krlvi added a commit to gitbutlerapp/turborepo that referenced this issue Nov 7, 2024
@krlvi
fix(filewatcher): handle removed directories vercel#8800
3d21e39 
When setting up manual recursive watching on folders (as is the case under Linux),
the watching thread should not exit if a directory no longer exists.
This is likely to occur within build output directories and it should
not be the cause for interrupting the daemon.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind: bug Something isn't working needs: triage New issues get this label. Remove it after triage
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix(filewatcher): handle removed directories #8800 gitbutlerapp/turborepo
4 participants
@Byron @JCMais @krlvi @anthonyshew