Non-deterministic typecheck LSP errors when modifying a transitive import of a file

[thufschmitt]

Describe the bug

Modifying a file that is a transitive import of another one leads to some weird typecheck-related diagnostics from the parent one.

The gif below illustrates that: foo.ncl imports bar.ncl which in turn imports baz.ncl, and modifying baz.ncl triggers some semi-random diagnostics in foo.ncl

The gif doesn't show it, but all the errors in foo.ncl are

import of /tmp/tmp.MTYXidOIhu/bar.ncl failed: This import could not be resolved because its content has failed to typecheck correctly.

These errors seem to be very state-dependant. Sometimes an invalid file will trigger them, sometimes not. And sometimes a valid file will trigger them. They are also only triggered on foo.ncl, never on bar.ncl.

To Reproduce

1. Create the files

   cat <<EOF > bar.ncl
   let baz = import "baz.ncl" in
   {}
   EOF
   cat <<EOF > baz.ncl
   {
     x,
   }
   EOF
   cat <<EOF > foo.ncl
   let bar = import "bar.ncl" in
   {}
   EOF

2. Open an editor with lsp enabled, and find a monkey to randomly change the content of baz.ncl
3. Give the monkey a banana as a reward

Expected behavior

One of

1. No change is automatically propagated, so no error appears until the focus goes back on bar.ncl or foo.ncl
2. All the changes are propagated, in which case bar.ncl shows an error, and foo.ncl too (but something else than a typechecking error)

Environment

• OS name + version:
• Version of the code: 1.6.0

Additional context
Add any other context about the problem here.

[jneem]

I think #1944 makes this deterministic, but I think the behavior can still be improved. Some (but not all) errors in the imported file trigger an error in the file that imports them, so now it's quite easy to make an error in bar.ncl show up by fiddling with baz.ncl, but it's pretty hard to make an error in foo.ncl show up...