Fix converging edges swapping positions when selected

[lmac-1]

Description

This PR fixes a bug where converging edges would swap positions when selected on the diagram.

The issue was caused by sortOrderForSvg reordering edges based on selection state, which affected Dagre's layout decisions. The fix preserves stable edge order regardless of selection.

Before:

After:

See the bug in action: https://www.loom.com/share/302055f6f3b748f1a4523ef7ccef67af

Closes #4328

Validation steps

1. Open workflow with multiple branching points
2. Make sure your diagram is on auto layout mode
3. Click edges from different parent nodes
4. Click edges that lead to converging paths
5. Expected: All paths maintain their positions

Additional notes for the reviewer

1. If you have bigger workflows - perhaps click around on the paths and make sure that everything behaves as expected
2. I suspected that this sorting algorithm was to ensure that the edges stayed on top in terms of z-index. I've verified both with and without the fix that the behaviour remains the same when there are edges that are on top of each other.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

• I have used Claude Code
• I have used another model
• I have not used AI

You can read more details in our
Responsible AI Policy

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review
  with Claude Code)
• I have implemented and tested all related authorization policies.
  (e.g., :owner, :admin, :editor, :viewer)
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.33%. Comparing base (549de66) to head (b398d4e).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4348      +/-   ##
==========================================
+ Coverage   89.29%   89.33%   +0.04%     
==========================================
  Files         425      425              
  Lines       19994    19994              
==========================================
+ Hits        17854    17862       +8     
+ Misses       2140     2132       -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[doc-han]

Works perfectly 🎉
Can we remove the comments with the PR number in them?

Also, I'm yet to understand why the sort function was initially made to work in that manner(pushing the selected edge to the bottom).

[doc-han]

Can we remove the comments with PR numbers? Thanks.

[lmac-1]

@doc-han thanks for the review. I've fixed the comments referring to the PR. Can you check it again?

Also re the sorting function, I asked my good friend Claude and it seems to think that it "ensures disabled edges render behind enabled edges in the SVG." So I think it's best if we keep it in!

[doc-han]

@doc-han thanks for the review. I've fixed the comments referring to the PR. Can you check it again?

Also re the sorting function, I asked my good friend Claude and it seems to think that it "ensures disabled edges render behind enabled edges in the SVG." So I think it's best if we keep it in!

Yeah makes sense. I was more concerned as to why the line had return a.selected - b.selected; because with the sort function, getting there meant the two values being compared are equal, so I'm wondering why we needed to sort based on another criteria which is .selected

[lmac-1]

@doc-han are there any further changes needed here or can this be approved?

[doc-han]

Hi @lmac-1 sorry for the delay. I was doing a deep dive into this.

Why sortOrderForSvg

1. React flow assigns z-index to edges based on their order in the edges array. eg. [edge1, edge2] edge2 will have a higher z-index
2. Hence, the sort function sortOrderForSvg existed to make sure that the selected edge will always be at the bottom of the edges array. so that when two edges overlap, selecting either will always put it above the other.

Side Effect of sortOrderForSvg with Dagre

We then had a side-effect, Dagre(a library we use for calculating layouts) also depends on the order of edges to determine which edge/node shows left-most when a parent has more than one children.

So the function sortOrderForSvg actually existing for solving z-index but had a side-effect of altering how Dagre also calculated its positioning.

This solution

The solution in this PR tries to make Dagre satisfied by ensuring that edges always reach Dagre in the same order but then breaks the z-indexing reason why sortOrderForSvg existed.

Regression on this branch

When two edge labels overlap on this branch, the selected one doesn't get z-index precedence.

Existing Regression on main

Looking at the logic in sortOrderForSvg, it tells me the problem also exists when you enable/disable an edge, the nodes will shift. Hence, that's something we also need to take care of.

Proposed Solution

We handle the z-index well and get rid of sortOrderForSvg. I think this is a problem react-flow is also realizing recently, so they just added a new way of handling z-indexing. This will require updating our version of react-flow and using the new z-index feature they've introduced. This will solve both problems.

zIndexMode in ReactFlow

[doc-han]

In short, this change swaps out the bug for another one by breaking the below feature.

It also doesn't handle the case for when the edge is being enabled/disabled which also gets us to the same issue.

@lmac-1 let me know whether you'll want to take on this, else I could pick it up.

[lmac-1]

@doc-han great catch! I think it would be better if you could pick this up if you have time. I'm flying to the UK tonight and won't be online much more this week.

[doc-han]

@doc-han great catch! I think it would be better if you could pick this up if you have time. I'm flying to the UK tonight and won't be online much more this week.

Safe flight. I'll pick it up then

[lmac-1]

Thanks a lot @doc-han - I appreciate the deep dive on this one.