Subgraph direction ignored and incoming edges clipped at cluster border since 11.16.0 #8066

Description

Since v11.16.0, a direction declared inside a subgraph is ignored when that subgraph's nodes have no edges between themselves, and every edge coming into that subgraph from outside stops at the subgraph border instead of reaching its target node.

Both symptoms appear together, from the same diagram source, and both are regressions: the exact same source renders correctly on 11.15.0.

In the sample below, the Orgs subgraph declares direction TB and receives one edge per node from the Branches subgraph:

• On 11.15.0, Orgs stacks vertically and each edge ends on its target node.
• On 11.16.1, Orgs is laid out horizontally along the parent LR axis, and all three edges stop on the left border of the cluster, with their arrowheads piling up there.

This is a common shape for pipeline-style diagrams: a horizontal chain on one side, a vertical list of targets on the other, and edges crossing between them.

Steps to reproduce

1. Render the diagram from the Code Sample below with mermaid 11.15.0.
2. Note that the nodes of the Orgs subgraph are stacked vertically, and that the three dotted edges each end on org1, org2 and org3.
3. Render the exact same source with mermaid 11.16.1, changing nothing else.
4. Bug: the Orgs nodes are now laid out horizontally, direction TB having no effect, and the three dotted edges stop at the left border of the Orgs cluster instead of reaching org1, org2 and org3.

Screenshots

Expected — mermaid 11.15.0. Orgs respects direction TB and every edge reaches its node.

Actual — mermaid 11.16.1. Orgs is laid out horizontally and the three edges stop on the cluster border.

Code Sample

flowchart LR
  subgraph Branches
    dev --> uat --> main
  end
  subgraph Orgs
    direction TB
    org1([org1])
    org2([org2])
    org3([org3])
  end
  dev -.-> org1
  uat -.-> org2
  main -.-> org3

Setup

• Mermaid version: 11.16.1 (broken) / 11.15.0 (correct). 11.16.0 not tested separately.
• Browser and Version: Chrome 141 (headless, driven by puppeteer), Windows 11

Rendered by calling mermaid.run() on the bundled dist/mermaid.min.js, with securityLevel: 'loose' and the default renderer. No layout plugin installed.

Suggested Solutions

The distinguishing factor seems to be whether the subgraph has edges between its own nodes:

• Branches has internal edges (dev --> uat --> main) and behaves the same in both versions.
• Orgs has no internal edges, only incoming ones, and is the one that loses its direction and gets its incoming edges clipped.

Adding an invisible chain between the org nodes (org1 ~~~ org2 ~~~ org3) gives that subgraph internal edges and does restore the vertical stacking on 11.16.1, which supports this reading. It does not fix the clipped edges, so the two symptoms may have a common cause in how a cluster's own layout is computed and then positioned in the parent graph.

Additional Context

Checked while narrowing this down. None of these change the outcome on 11.16.1, so they can be ruled out:

• The flowchart.curve setting: monotoneX, linear, basis, or no %%{init}%% block at all.
• classDef / :::class styling, linkStyle, and click handlers.
• Whether the edges are declared inside the subgraph or after both subgraphs.
• Node shapes and edge labels.

Workarounds tried, none usable:

• The invisible chain described above restores the vertical stacking on 11.16.1 but leaves the edges clipped, and it distorts the layout on 11.15.0, where the nodes become a diagonal staircase.
• Removing the direction declaration keeps the edges clipped and leaves the nodes horizontal.

Reported from vscode-sfdx-hardis, where this broke the DevOps pipeline diagram. We pinned mermaid to 11.15.0 for now, as we could not find a source-level workaround.