Fix FileWatcher
ordering bug
#51
Labels
part:core
Affects the core types (`Sender`, `Receiver`, exceptions, etc.)
resolution:invalid
This doesn't seem right
type:bug
Something isn't working
It looks like ordering is important here and I don't think
set
preserves order. Also, why do we want to compressFileChange
s that are the same, suppose we have this sequence:/a
is added/a
is deleted/a
is added againWith this implementation we could only get one add and one deletion so we would think the file doesn't exist but it does.
If this introduced a bug that wasn't detected by test, we should probably add a test for this too :)
Originally posted by @leandro-lucarella-frequenz in #42 (comment)
The text was updated successfully, but these errors were encountered: