Windows error tag (-1) is outside of enumeration's range (0,4)

[supermario]

I've had users report the following crashes happen occasionally in a scenario where we're using fsnotify to watch the disk for file changes:

lamdera.exe: toEnum{Action}: tag (-1) is outside of enumeration's range (0,4)
CallStack (from HasCallStack):
  error, called at win-src\System\Win32\FileNotify.hsc:46:34 in fsnotify-0.4.1.0-7SQlBibA4qu3CuGnOcBOvF:System.Win32.FileNotify

I'm guessing this is related to:

hfsnotify/win-src/System/Win32/FileNotify.hsc

Lines 42 to 46 in cff8882

	readDirectoryChangesW h buffer (toEnum maxBuf) wst mask bret
	readChanges buffer
	data Action = FileAdded | FileRemoved | FileModified | FileRenamedOld | FileRenamedNew
	deriving (Show, Read, Eq, Ord, Enum)

As it's the only place toEnum is used in this package. But I'm unsure what the -1 value would indicate in Windows or how to debug further.

Would be happy to add debugging/instrumentation code if someone could provide some guidance, but otherwise we don't currently have a sure-fire way of replicating the issue reliably.

[thomasjm]

I see another toEnum usage a few lines down:

hfsnotify/win-src/System/Win32/FileNotify.hsc

Line 57 in cff8882

faToAction fa = toEnum $ fromEnum fa - 1

It looks like Windows gives us action enums with a value between 1 and 5 inclusive, see here.

It appears that this line is converting from the 1-based Windows indexing to the 0-based Haskell Enum indexing. But somehow Windows is sending 0 for the action, resulting in a call to (toEnum (-1))?

[thomasjm]

If you have a Windows dev machine handy, maybe you can load FileNotify.hsc in GHCi and check that the enums (FileAction and Action) have the expected values?