-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating fact sources' facts generates ghost facts during operations #2930
Labels
Comments
Guil33
changed the title
Updating fact sources' facts generates duplicated facts during operations
Updating fact sources' facts generates ghost facts during operations
Mar 26, 2024
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days |
Update: here are the 4 issues I have identified, summed up:
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
If a fact defined in a Fact Source is updated, operations created using this Fact Source will be able to access the old fact value as well, thus creating multiple links (since several values "exist" for this fact).
I will include a detailed example for clarity after the simple
To Reproduce
part.To Reproduce
Steps to reproduce the behavior:
ping #{host.network.ip}
host.network.ip
(2 links are created).Expected behavior
From the documentation:
Fact source: You can attach a source of facts to an operation. This means the operation will start with “pre-knowledge” of the facts, which it can use to fill in variables inside the abilities.
A fact source is a collection of facts that you have grouped together. A fact source can be applied to an operation when you start it, which gives the operation facts to fill in variables with.
In the light of these lines, I expect that Caldera:
This means in that case, that the old Fact value(s) should not exist within the context of the operation created with the updated Fact Source (or anywhere else really). Therefore, there should only be one link generated, using the new Fact value, and we shouldn't see the previous Facts values or Facts being used at all.
Detailed example
(Bug in step 6)
host.network.ip
with value192.168.1.1
host.network.ip
host.network.ip
with the new value is added to the Operation (random print inOperation._init_source
inc_operation.py)
host.network.ip
thus 2 links are created.object_store
. There is only one value for the Fact, and the correct one.Bonus tests
host.network.value
removed entirely from the Fact Source, there are no Facts added in_init_source
, but the 4 values still exist (even before_init_source
is called).Conclusion
The old value for the Fact remains in memory somewhere, even though I have been unable to locate where.
object_store
(checked in Step 8).From the bonus tests, I assume there isn't really any way to get rid of old facts / old fact values, save for deleting the Fact Source and creating a new one, because the Facts remain somehow bound to the specific Fact Source they were created in (tested in Bonus).
I did notice that updating the Fact value in the Fact Source triggers a write operation to a yaml file in
data/sources
, but this file does not seem to be read in later operations (at least I didn't see it), so I'm not sure what to think of it. However, this seems to be the most promising lead at the moment.Desktop
Server
Additional context
atomic
planner) in the reverse order they were created: if the Fact had value1
, then updated to2
, then updated to3
, the links are generated with the current value first, then the old ones:3
->2
->1
origin_type
asSEEDED
, and thesource
being the correct yaml file indata/sources
, which looks ok when reading it (i.e. only 1 Fact, or none at the end of my tests).The text was updated successfully, but these errors were encountered: