dependency-view-web 1.0.2 - message "Dependency map structure changed repeatedly" persists after page reload

[K0nne]

Describe the bug

Hello!

Today we have installed the new icinga-dependencies-web 1.0.2 module. This message appears after each page reload, but it states it shouldn't.

To Reproduce

I have just installed icinga-dependencies-web-1.0.2-1.el8.noarch.rpm on our qs masters.

Expected behavior

It seems this message should vanish.

Screenshots

Your Environment

Include as many relevant details about the environment you experienced the problem in.

• Icinga DB Web version (System - About): 1.2.3
• Icinga Web 2 version (System - About): 2.12.5
• Web browser: current edge
• Icinga 2 version (icinga2 --version): 2.15.1
• Icinga DB version (icingadb --version): 1.4.0
• PHP version used (php --version): 8.2.28
• Server operating system and version: rhel8.10
• Dependency View 1.0.2

[K0nne]

10 minutes later and the message is gone. Seems to be something which happens only directly after installation (maybe after some internal structure are built up). I close this.

[K0nne]

When I hit Strg + F5 this happens and the messages appears every time.

03-12-2025_08-01-35.mp4

I use a 4k monitor with a 3440 x 1440 resolution.

[K0nne]

If I stay on the dependency map page for some time and it auto-refreshes, the error messages starts to pile up and they won't disappear after some time like normal icingadb-web messages:

[nilmerg]

The map invalidates it's structure on its own based on several facts. We know of a similar issue in an environment where hosts and services come and go frequently or relations change often (e.g. hostgroup memberships). Is this possibly also the reason on your end? Though, for this to have an effect on the map, such changes must happen every few seconds, which I doubt is the case so commonly.

The error messages persist as they're configured to do so, as the error is something that should absolutely not occur and the intended effect is that users tell us about it, which works as designed as you see. 😁

And is it correct that I assume the video shows you hitting CTRL+F5 five times? I hope so, because I would not be able to explain that behavior otherwise. 😅 At least not with the normal refresh timings.

To pin down the cause, the first thing you can do is:

• Open http://…/icingaweb2/dependencies/map/v2/structure?invalidate in the browser or download it with e.g. curl, save it in a file (The ?invalidate part is very important, otherwise you'll get cached results)
• Then wait a few seconds
• Do the same again, save it in a different file and compare both with e.g. diff
• The files should not differ

Repeat the same process with the result of http://…/icingaweb2/dependencies/map/v2/states (There's no ?invalidate as there's no cache involved). Though before you can compare both results, you will need to adjust them. There are states of dependencies contained which are expected to change and need to be ignored.

awk or jq will do the job :)

awk -F',' 'BEGIN {OFS=","} {print $1,$2,$4}' result.txt
jq -c 'del(.[2])' result.txt

If you get no difference in both cases, open up the map in the browser and see if the issue appears. If not, the next time you have the issue, repeat the processes above and a difference should appear as well. 🤞

[K0nne]

Hi @nilmerg, sorry for being late. I totally forgot to respond. I will get to it soon!

Just an idea for the module:
It would be nice the have a permission-setting to disable the access to the dynamic dynamic-map, because the map distracts without adding functionality for us.

[K0nne]

And is it correct that I assume the video shows you hitting CTRL+F5 five times? I hope so

Unfortunately no. It happens on its own.

Test-results:
Upon further tests, the errors corelate with icingadb-webs's refresh. Upon fast interval, the also come fast and vice versa.

http://…/icingaweb2/dependencies/map/v2/structure?invalidate:
I compared 2 results with an error between -> no differences.

http://…/icingaweb2/dependencies/map/v2/states:
I compared 2 results with an error between -> a single state at position 2 differs
I normalized both results with jq -c 'del(.[2])' filename ->no differences

The error is still there :D

[nilmerg]

Thanks for reaching out again!

Unfortunately no. It happens on its own.

But this contradicts:

If I stay on the dependency map page for some time and it auto-refreshes, the error messages starts to pile up and they won't disappear after some time

As mentioned, they are designed to stay and only disappear if you dismiss them or the entire layout is reloaded. Which is why I assumed that you reload the page repeatedly in the video, to show that the error appears every time again.

The messages piling up may have legitimate reason, I just have to replicate it somehow to identify probable causes. That's not what worries me. It's what the video shows, that the map clears and notifications disappear repeatedly. If this happens again, please note the URL in the address bar and share the parameters with me, if there any. I don't know of another reason that may cause this behavior.

no differences.

That's good, at least it limits the probable causes to the client side…

It would be nice the have a permission-setting to disable the access to the dynamic

That's of course an option but I would really like to understand what's going on here…