SVG visualisation breaks on dependencies between tasks with the same name about luigi

[starhel]

I have encountered the same issue - I have tasks that iteratively trigger themselves (aggregating data in 7-day buckets -> 28-day buckets -> N-day buckets). @dlstadther would there be a chance for you to take a look at it when you have a moment (as reviewer of #3122)?

[dlstadther]

Based on this issue, i understand there to be rendering issues with the SVG visualization here in Luigi. I have no insight to provide towards a solution. I welcome any contributions to the project and I'll do my best to provide reviews (though time has been in short supply for a few years now as my day job no longer uses Luigi).

[ewallace-RI]

To my mind, the solution would simply be to revert the changes from #3122, which broke the existing functionality for the sake of someone's aesthetic preference in their use case. Given that the change had been in place for 2 years by the time I upgraded and noticed it, I figured that would be an unpopular solution, and opted to just overwrite that .js file in my local installation.

I didn't see an obvious way to make the fallback to the old behavior in the presence of dependencies between same-named tasks work while keeping the new behavior otherwise, and since the new behavior is useless to me, I didn't have much motivation to put more effort into finding a fix that would preserve it.

[dlstadther]

@joooeey , being the author of the PR which is causing issues for the use cases mentioned above by @ewallace-RI and @starhel , do you see a clear path to resolution?

[starhel]

I've fixed case with (NaN, NaN) in; #3287
For now I have no time to find solution for non-directly dependent tasks.

[joooeey]

I don't use Luigi anymore, so I don't have the time to contribute a tested solution. However, I can see that this line in the visualizer code only checks for direct dependencies to tasks of the same name. To also capture indirect dependencies, the $.each loop would have to be adjusted to build up an array of known names. Then child_node.name can be compared with that array.

#3287 is also necessary and it should be checked how that PR interacts with the change I propose in the previous paragraph.