Skip to content

Conversation

@jschrempp
Copy link

In my last PR the graph of the return route was shown incorrectly. It did not account for the fact that the return route was in reverse order in the route blob.

This PR adds two things:

  1. /graph/traceroute now looks for the .done column in the traceroute set it is graphing. It will reverse the order of the graph is the .done column is true for all the traceroutes.
  2. To avoid unintended consequences, if even one traceroute has done = false then the old behavior will be followed
  3. If someone runs this on a database with old data in it, from before we loaded the return routes, then an error is displayed if they try to view a return route where there is no data.

I tested this on my system with an old database and with a new database. (For testing on old database I had to comment out the route_return blob in the model.)

@jschrempp
Copy link
Author

I don't understand the ruff error. I'm willing to fix it if someone could give me a hint on how to see what it is complaining about. Or do I just run the "let ruff reformat the web.py file" and see what happens? I'm new to this.

@logans-stuff
Copy link

not sure how much help this is, but i was able to run ruff format --check and was able to build this locally. There seems to be some various issues still lingering with TRs. Some TRs flat out fail to load from DB it would appear, but the return match behavior seems to be alot better in this patch.

for example: graph/traceroute/1946375304 packet/1946375304 but then clicking tr graph on page you get sent elsewhere /graph/traceroute/992387893
asdsdasdda
sdfsdfsdfd

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants