Nodes not staying in saved position

[twcallaghan]

Description

---

When the map is reloaded (as in the website is completed reloaded) the nodes either move back to the positions they were originally in when created or they are moved to a random location on the map.
I have seen both behaviors happen with entity nodes but I was unable to recreate this issue with custom nodes. The issue also only seems to happen with large amounts of nodes.

Steps to Reproduce

---

In the export below, to recreate my issue, take a few of the nodes and move them far away from their current position. Wait a few seconds to ensure that all the locations have been saved. Reload the webpage.
The arrows and order is all nonsense to recreate the issue without sensitive data.

Below is the export of the data in .txt.
nodebreak_export.txt

Expected Behaviour

---

The expected behavior is that nodes stay saved in the position they were moved to after getting the notification that their location has been saved.

Relevant Logs / Console output

---

Export of data in a .txt
nodebreak_export.txt

Your Environment

---

NR1 CLI version used: (not used)
Browser name and version: Google Chrome 85
Operating System and version: Windows 10 Enterprise version 1809

Here are some screenshots to better understand it (look at the two green nodes that are very high):
Before reloading the page:

After reloading the page:

[Kav91]

I have a feeling this could occur if its out of bounds, eg. the node going into a negative boundary so the y coordinate could be negative.
When you move the node higher up, are you dragging the map itself down first?

[twcallaghan]

@Kav91 No I was not dragging the map down before moving that node. I may have zoomed out though as you can tell there are many nodes that are fairly spread apart. I'm investigating the issue with possibly having a negative boundary value now.

[twcallaghan]

@Kav91 Update on the values of the node's location:
Here is what the this part of the map and value of the highlighted Node's location is without moving anything.

Now when the highlighted node is moved up, possibly into a "negative boundary" as you described, this is what happens:


The only way that I can tell something isn't right is because it is an integer not a decimal value. When I moved the node further, I got other integer values every time but when I moved it down to where it originally was there were decimal values for the y coordinate.
I was never able to get it to display a negative value, only these kinds of integers.

[sekrish]

have faced this issue too. definitely impacts the presentability of the dashboard. Would it help to make the node positions be able to 'snap-to-grid'. the utility of being able to drag the nodes around arbitrarily is possibly less than having them stay static and be able to display more data around the nodes.

[twcallaghan]

What would be the best way to fix this issue as the user's behavior is going to cause issues with this in my organization as the observability maps we will be using contain many nodes, some over 100. If it is possible to be able to see where the nodes are crossing into negative values that would be amazing, otherwise what do you recommend? Thanks in advance!

[sekrish1]

how/where do you see the x and y coordinates for the nodes above?

[twcallaghan]

@sekrish I see them after clicking the "export" button. Find your specific node in the jumble of information and it shows you something like this:

The x and y coordinates update dynamically too whenever the nodes move. What I was saying is that it is only an exact integer when it is supposed to be a "negative value". I'm sure you can test it yourself by zooming out and moving a node upwards... observe how the y coordinate will get closer to 0 with decimals, then 0, then start going upwards again but with integer values.
Hope this helps!

[twcallaghan]

@Kav91 Is there any update on a resolution for this issue? It would be greatly appreciated by myself and the entire organization I work for! Thanks!

[Kav91]

hi @twcallaghan I've been exploring solutions. Observability Maps depends on react-d3-graph so in the past when I attempted to give nodes their own x,y position if they went out of bounds it wouldn't update the map.

I had raised an issue quite some time ago -> danielcaldas/react-d3-graph#295 they did close it but I'm not sure if it will fix it as the PR states its for initialization -> danielcaldas/react-d3-graph#353. I need to test it out to see if can be used to bounce the nodes back if they do get positioned out of bounds.

[twcallaghan]

@Kav91 I understand what you are saying. If it was possibly easier, my thought was to make a defined border in a different color that shows where you should stop putting nodes (basically where the bounds are). This would be massively helpful in making large observability maps as you wouldn't have to guess or constantly check if your nodes are going out of bounds.
Thank you for trying to help and please keep me in the loop about it all!

[Kav91]

I've just merged the following PR #49 . I'm hoping that this will help keep nodes with positive coordinates within the map bounds. So should prevent unexpected behaviour when reloading and it then appearing in a randomized location.
If you node is bounced to a positive location, you should then move it to your desired location so the new coordinate can be written back.

It won't be immediately available till the nr1-catalog is updated which will be pending this PR newrelic/nr1-catalog#159 .

I will leave this issue open till you all are able to test it out.

[twcallaghan]

@Kav91 So I noticed the changes you made and they're definitely on the right track as the nodes are no longer appearing in random places. They instead seem to be placed back in the positions they were originally in before moving.
This is definitely a step in the right direction and I really appreciate the work put into it! However, what I was really hoping for was a way to know that my node had gone out of bounds without having to reload the webpage/map. Below shows two images, the before and after of moving two nodes, and it's great that they go back to original positions but I am working with maps that have dozens or hundreds of nodes and need to know sooner than reloading a webpage if they won't be staying in that position.

These nodes also still appear as positive integers when they go into "negative" values which I think should be a bug (also displayed below in an image).

Thank you for the support, again I really appreciate the effort!

[twcallaghan]

@Kav91 Hope all has been well with you with the new year! I was wondering if there has been any updates on the possibility of keeping the nodes in negative locations at that location/adding a graphic or preventing the user from moving nodes into negative locations? Thanks!

[Kav91]

@twcallaghan thank you, hope yours was as well. Users should now be unable to place nodes in negative locations.
If it is dragged to a negative coordinate it should be rejected and be moved back to a positive coordinate.

[twcallaghan]

@Kav91 Thank you, it has been!
So what is currently happening on my end is when I move a node into a negative coordinate it will stay there until the page is reloaded (not the map refreshing), and then when the entire webpage is reloaded, the node will move back to its last positive position.
The main problem I am facing with this solution is that the nodes aren't moving back upon the map refreshing but when the webpage is reloaded which realistically wouldn't happen much when someone is using it. The other, bigger, issue is that I don't know when a node goes into negative values unless I go to export and find the node coordinates manually.
Would it be possible to add a graphic to the maps to show the bounds? Or perhaps have the nodes move back upon the map refreshing instead of the entire webpage being reloaded?
I really appreciate all the work that has been done by you and your team on this by the way! Some of the best support I've ever gotten!

[Kav91]

@twcallaghan Thank you for the kind words.
The behaviour should be to reject the node straight away and not wait for a refresh. My local build serving from master branch is behaving like that, but the current version in the catalog which should be the same version doesn't have the same behaviour for some reason. I think there has been some deployment problem. Let me dig into it, maybe I'll try and get a dummy PR/version release bump.

Edit: Submitted catalog update here -> newrelic/nr1-catalog#188 will wait for this to get merged and retest the behaviour of the public/catalog version again.

[Kav91]

@twcallaghan Are you able to test and let me know how it is now, I've had another few fixes get merged in a newer release that is out now. I also had another colleague who I believe had the exact same situation as you and required a refresh so was able to debug with him. Hoping its sorted now 🤞

[twcallaghan]

@Kav91 I was able to test it today and can confirm that it seems to be working great!
I am going to await for my boss to test it to close the issue to double check that it is working exactly how we both are expecting it to. Thanks so much again for the persistent effort over the past many months on this!

[twcallaghan]

@Kav91 Going to close the issue now as my boss tested it and confirms that it has fixed our issue. Thank you so much for the help throughout the many months! Hope you have a great rest of the year!