Demote no access to the persisted file to debug messages

[fendor]

It is not really an error as it may happen if the file you want to lint had been closed before the lint can be applied.

[fendor]

@jneira with these changes, you should no longer see messages such as lintCmd: no access to the persisted file.!

[mpickering]

It could be argued that it's still an error if file was requested before it was inserted into the VFS and it's certainly an error to request a file which was never inserted into the VFS?

[fendor]

That is true. Unforutantely, we can not tell apart the cases right? Closing a file, removes it from the VFS, the lintCmd is stalled by runActionWithContext. So, opening a file then realizing you dont need it, closing it again, will show the "error" message to the user, although it is perfectly fine.

[lukel97]

Should these pending requests not end up being cancelled whenever the file is closed?

[fendor]

@bubba They are not, because the following might happen:
Open file in Editor, it gets added to the VFS -> request lint diagnostics.
Submit this to the scheduler. Scheduler schedules it and executes runActionWithContext which builds the context of the FilePath that we want diagnostics for. This might take a while since also dependency builds may be triggered.
Now the file in the editor is closed and the file is removed from the VFS.
However, we have no way of aborting building the dependencies, e.g. runActionWithContext is never aborted. After runActionWithContext initialises the context, the plugin hlint is executed to get the diagnostics which tries to access the temp file, but fails since the virtual file has already been removed.

[lukel97]

@fendor makes sense, these are all in IdeGhcM. But I thought we already had some logic to cancel requests that were in flight, at least whenever LSP sends a cancelRequest notification. Could this be called for any requests operating on a certain file that the VFS is told to close?

haskell-ide-engine/src/Haskell/Ide/Engine/Scheduler.hs

Lines 205 to 210 in dcf81a1

	cancelRequest :: forall m . Scheduler m -> J.LspId -> IO ()
	cancelRequest Scheduler { requestsToCancel, requestsInProgress } lid =
	STM.atomically $ do
	wip <- STM.readTVar requestsInProgress
	when (Set.member lid wip)
	$ STM.modifyTVar' requestsToCancel (Set.insert lid)

This could be made an issue or sorted out after this though

[fendor]

@bubba Does cancelRequest cancel actions that are already happening? Because that is the "problem" the action is already being executed, just stuck in runActionWithContext.

[lukel97]

@fendor Just actions that are queued from what I can tell

[jneira]

Well, as far i can test the alerts are gone from vscode and i can see them in hie.log. Thanks @fendor!