Incorrectly nested fact, only in UI

Support
1

Problem:
In the UI the fact is showing as empty, and as a nested fact.

Expected outcome:
The fact shows correctly, the same as it does in PSQL

Foreman and Proxy versions:

rubygem-hammer_cli_foreman_remote_execution-0.3.0-1.el9.noarch
rubygem-hammer_cli_foreman_ssh-0.0.3-1.el9.noarch
rubygem-foreman_vault-2.0.0-1.fm3_11.el9.noarch
rubygem-hammer_cli_foreman_salt-0.1.0-2.el9.noarch
rubygem-foreman_kubevirt-0.2.0-1.fm3_11.el9.noarch
rubygem-hammer_cli_foreman_kubevirt-0.2.0-1.fm3_11.el9.noarch
rubygem-hammer_cli_foreman_puppet-0.1.0-1.fm3_11.el9.noarch
rubygem-hammer_cli_foreman_tasks-0.0.21-1.fm3_11.el9.noarch
foreman-obsolete-packages-1.10-1.el9.noarch
foreman-release-3.13.0-1.el9.noarch
foreman-proxy-3.13.0-1.el9.noarch
rubygem-hammer_cli_foreman-3.13.0-1.el9.noarch
foreman-selinux-3.13.0-1.el9.noarch
foreman-3.13.0-1.el9.noarch
rubygem-foreman-tasks-10.0.1-1.fm3_13.el9.noarch
rubygem-foreman_remote_execution-14.0.2-1.fm3_13.el9.noarch
rubygem-foreman_salt-17.0.0-1.fm3_13.el9.noarch
foreman-dynflow-sidekiq-3.13.0-1.el9.noarch
foreman-libvirt-3.13.0-1.el9.noarch
foreman-ovirt-3.13.0-1.el9.noarch
foreman-postgresql-3.13.0-1.el9.noarch
foreman-redis-3.13.0-1.el9.noarch
foreman-service-3.13.0-1.el9.noarch
foreman-vmware-3.13.0-1.el9.noarch
rubygem-foreman_puppet-8.0.0-1.fm3_13.el9.noarch
rubygem-foreman_templates-10.0.1-1.fm3_13.el9.noarch
foreman-cli-3.13.0-1.el9.noarch
foreman-installer-3.13.0-1.el9.noarch
rubygem-foreman_maintain-1.8.1-2.el9.noarch
rubygem-foreman_statistics-2.1.0-3.fm3_11.el9.noarch

PSQL
image

UI
image

Ive even destroyed the host and re-pushed the facts. Same result.

2

My best guess would be that this fact used to be a nested fact or some host at least had it nested and thus is stored incorrectly in the DB due to faulty data in the past.
In PSQL, you can check:

select id, name, compose from fact_names where name='ssnc_server_role';

My guess would be that compose is true for your fact, which means “it is a nested fact”.
You can find any reported child facts via:

select * from fact_names where ancestry='<id from first query>';

If there are no child facts anymore in the DB, cleaning this up can probably be done by simply setting compose to false for your fact. If there are stored child facts, you will probably want to get rid of those first.
Disclaimer: Never had this problem myself, so I just took an educated guess on where it has probably gone wrong and how to most likely fix it.

1 Like
3

Brilliant. It worked perfectly, thank you!

1 Like