You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[fm] only you can prevent inventory collection time travel (#10266)
Depends on #10258.
As described in #10260 (and [§8.2 RFD 603]), **only _you_ can prevent
inventory collection time travel**: because each Nexus that might
participate in FM analysis has its own copy of the inventory which it
considers to be current (loaded by its `inventory_load` background
task). Since we must allow for the possibility of a particular Nexus
being arbitrarily behind, we can easily imagine a scenario where a Nexus
attempts to perform FM analysis and generate a sitrep while operating on
a copy of the inventory that is actually *older* than the inventory that
was used to produce the current sitrep. If this happens, we might
incorrectly think that the state of the system has _changed_ from the
state in the current sitrep, while actually, we are just operating on an
outdated understanding. This branch fixes that.
In #10260, I proposed addressing this by making the CTE that inserts a
sitrep into the sitrep history only succeed if the inventory collection
UUID in that sitrep's metadata is newer than the one in the current
sitrep's metadata. This would probably have worked, but putting that
check in the already somewhat hairy CTE was not actually necessary.
Instead, we can just perform this check *before* actually doing any
analysis, which feels a lot nicer. In order to do this, it was necessary
to add a query to just go and fetch only the timestamps from an
inventory by its UUID, which was not a huge deal. I think it is
plausible that the "is strictly newer than" check for inventory
collections may be useful elsewhere as well.
Fixes#10260
[§8.2 RFD 603]: https://rfd.shared.oxide.computer/rfd/0603#_inventory
0 commit comments