Skip to content

Fix FileWatcher ordering bug #51

@shsms

Description

@shsms

It looks like ordering is important here and I don't think set preserves order. Also, why do we want to compress FileChanges that are the same, suppose we have this sequence:

  1. /a is added
  2. /a is deleted
  3. /a is added again

With 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)

Metadata

Metadata

Labels

part:coreAffects the core types (`Sender`, `Receiver`, exceptions, etc.)resolution:invalidThis doesn't seem righttype:bugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions