gs-plugin-appstream: Race on appstream silo changes
This had been brought up downstream:
https://bugzilla.redhat.com/show_bug.cgi?id=2016510
(In reply to Owen Taylor from comment 21)<br>
> There's something else that I worry about with the xmlb cache revalidation -
> when we are rebuilding the cache, the sequence is:
>
> * Create a new XbSilo from the current content
> * Add watches
>
> So if a change happens between those two steps, it will get lost, isn't that
> right? But that should be rarer (though not *extremely* rare).
This can possibly happen. The simplest idea is to not set the file monitors on the silo, but have them on the plugin itself and invalidate the silo by the plugin.
How does that sound?