error: file not found (searched at <file path>) after 6999be

[itsjunetime]

Description

After commit 6999be9, running typst watch <file.typ> <file.pdf> shows the error error: file not found (searched at <file.typ>) whenever the file is saved (with or without modificiations) and doesn't write/save the generated pdf file.

This error occurs on 426445e as well (the only commit after the one that introduced the bug) and does not appear before 6999be9, as far as I can tell.

I tried to look at the changes introduced in 6999be9, but couldn't figure out what exactly might've caused this issue as I'm not familiar with the codebase.

Reproduction URL

No response

Operating system

Linux

Typst version

• I am using the latest version of Typst

[laurmaedje]

@frozolotl any ideas?

[laurmaedje]

Can't reproduce on macOS.

[frozolotl]

@frozolotl any ideas?

I have absolutely no idea. I can't think of anything that might cause this issue.
There previously was this line¹ which ignored the error and now doesn't, but I don't think that could be the reason.

I can't reproduce it on Linux either.

@itsjunetime, can you start a new shell, run cargo clean, compile the project, and then check again that 6999be9 is definitely the first commit with that issue?
Then repeat the same steps and verify that the issue does not occur with the prior commit 51854ba.

Footnotes

1. https://github.com/typst/typst/commit/6999be9ab0d851d0b3b34bd311712c27887721f1#diff-15008dd52f222c99ec86bdeaf166b0cd4a55f61b2b1f4f4ba37f5feb9d2858bbL160 ↩

[itsjunetime]

So it looks like it does only reproduce after 6999be9, but also only happens when I save from neovim. If I do echo a > test.typ while watching test.typ, or save it in nano, this issue doesn't appear. But opening the file in neovim and running :w does make the issue occur.

Perhaps neovim does something like deleting the file and then re-creating it, which causes a race condition in how we watch the file?

[itsjunetime]

Ah, yes - if I run :set backupcopy=yes in neovim (per this stackoverflow question), I don't run into this issue anymore.

[Leedehai]

Team - is it a good idea to let Typst pause for like 100 milliseconds before recompiling upon a file change event?

It might be able to address this issue - I think many vim (or apps that act similarly) users would run into it.

[Dherse]

I am having a similar issue with VSCode which may be caused by this same commit (as per @frozolotl), when I save in VSCode, it causes two incremental compilations in a row, while it's not major in itself, it makes doing performance measurements in incremental for #3307 very difficult.

EDIT: running on Ubuntu 22.04.3 LTS under WSL, everything up-to-date, etc.

[laurmaedje]

Team - is it a good idea to let Typst pause for like 100 milliseconds before recompiling upon a file change event?

Integrating an intentional lag would be very unfortunate. I think we should also not jump to this quite as quickly since the problem is new and we haven't added intentional lag before either. I really wonder what caused this.

[laurmaedje]

@frozolotl I read the diff again and this looks very sus, not sure why I didn't notice that in code review: https://github.com/typst/typst/pull/2665/files#diff-ea95583ebe87e25ee323e9ad5d1a654f2fbf243e9f4d1727c49d7271585149bdL40-R46

Why was this changed again? It skips all but the first event in the queue. Note that the old code had a double-loop where the new one has a single one.

[frozolotl]

@frozolotl I read the diff again and this looks very sus, not sure why I didn't notice that in code review: https://github.com/typst/typst/pull/2665/files#diff-ea95583ebe87e25ee323e9ad5d1a654f2fbf243e9f4d1727c49d7271585149bdL40-R46

Why was this changed again? It skips all but the first event in the queue. Note that the old code had a double-loop where the new one has a single one.

It was originally changed so that the is_active() check is performed regularly.
I later added another timeout where after 750 ms the application is forcibly shut down using process:exit().
That would make this change workable, but not perfect, as the user would have to wait around 750 ms for the process to exit.
I'm now working on a fix that tries to keep the quick exits, while supporting editors' remove&move.

[laurmaedje]

Would they really have to wait that long? The event receiving in the for loop has a timeout of 100ms after all.

[frozolotl]

Would they really have to wait that long? The event receiving in the for loop has a timeout of 100ms after all.

Prior to my change and in the proposed patch #3364, yes. That's because there first is a rx.recv() call, which does not do timeouts at all. The timeout is only done after one event is received.

[laurmaedje]

Makes sense.