Architecture diagram - different layout rendering each time

[hakanson]

Description

The same architecture-diagram mermaid code will render differently on reload/refresh. I would guess the layout engine is non-deterministic somehow. Different versions result in angled lines (non orthogonal routing) and un-aligned arrow heads.

Steps to reproduce

1. Load the diagram below
2. refresh page
3. refresh page
   ...

architecture-beta
  service client[Client]
  group awscloud(logos:aws)[AWS Cloud]
    service api(logos:aws-api-gateway)[Amazon API Gateway] in awscloud
    service lambda1(logos:aws-lambda)[AWS Lambda] in awscloud
    service dynamodb(logos:aws-dynamodb)[Amazon DynamoDB] in awscloud

    client:R -[1]-> L:api
    api:R -[2]-> L:lambda1
    lambda1:R -[3]-> L:dynamodb

    service s3(logos:aws-s3)[Amazon S3] in awscloud
    service lambda2(logos:aws-lambda)[AWS Lambda] in awscloud
    %% junction junctionRight

    client:B -[4]-> L:s3
    s3:R -[5]-> L:lambda2
    %% lambda2:R -[6]- L:junctionRight
    %% junctionRight:T --> B:dynamodb
    %% to fix diagram, uncomment all junctionRight above, and comment out line below
    lambda2:R -[6]-> B:dynamodb

Screenshots

These are 5 different rendering of the same diagram without change any mermaid syntax

Code Sample

https://develop.git.mermaid.live/edit#pako:eNqVU01Lw0AQ_SvDgqDQHGzUQw6CbUEEBbGCh6aHSXabru5H2WysVfzvTneTGHtQPHXmzds3byadD1ZaLljG0JVr6UXpGyeSQnjMDUAt3KssBZRKCuMX0_Cz3FcqZ5sN4LYulW34sbKVrTNKTxZXT3OY7sHA-9bAjfymJZQlFXqxxR090fhuDVzd38B1xJYgTa_-U0ehLjieDrQiEjvfhviX53xnUFteDN53UG9kFoDZ5EAmCsVdZA-QLE6XySXcZjRLLFEQ8HHEW6ex1iahnsZ617dT7izW6cBcnfa25umfaxn_dy1HR_DcmNJL0u-CB1mt_cG4E7J9Fm3Xads5DcOcD4cd96ptHigXy4QYB_IH3QOaPUJCapPBalqat7CSb8AlVg71COiV1ZqcASr1UwSwsK9iBGg4dCTbeFDSCCiEstvhF-kdDtuyEdPCaZScLuNjT8-ZXwstcpZRyNG95Cw3n8TDxtv5zpQs864RI0Z3Ua1ZtkJVU9ZsOP2hZ9F1jwouvXV38fDC_X1-AWN9L2Q

Setup

• Mermaid version: 11.4.1
• Browser and Version: Edge

Suggested Solutions

No response

Additional Context

The best way I found to fix layout is to add a junction for a hint on step 6

architecture-beta
  service client[Client]
  group awscloud(logos:aws)[AWS Cloud]
    service api(logos:aws-api-gateway)[Amazon API Gateway] in awscloud
    service lambda1(logos:aws-lambda)[AWS Lambda] in awscloud
    service dynamodb(logos:aws-dynamodb)[Amazon DynamoDB] in awscloud

    client:R -[1]-> L:api
    api:R -[2]-> L:lambda1
    lambda1:R -[3]-> L:dynamodb

    service s3(logos:aws-s3)[Amazon S3] in awscloud
    service lambda2(logos:aws-lambda)[AWS Lambda] in awscloud
    junction junctionRight

    client:B -[4]-> L:s3
    s3:R -[5]-> L:lambda2
    lambda2:R -[6]- L:junctionRight
    junctionRight:T --> B:dynamodb
    %% to fix diagram, uncomment all junctionRight above, and comment out line below
    %% lambda2:R -[6]-> B:dynamodb

[hakanson]

might be a duplicate of #6024

[NicolasNewman]

After taking a look at the above issue and the one outlined in #6024, the underlying causes are different and should be considered separately.

The problem in this scenario is that the parser should technically be throwing an error, despite it looking valid.

One of the limitations of the underlying engine used for generating the layouts is that to enforce a clean grid pattern, each node needs to be no more then one "unit" away in X and Y direction.

To make it a bit more clear, I changed the 3rd edge from lambda1:R -[3]-> L:dynamodb to lambda1:R -[3]-> T:dynamodb

In this case, we'll call client the origin at [0, 0]. That means api is at [1, 0], lambda1 at [2, 0], and dynamodb is at [3, 1].

The issue lies in that s3 is located at [1, 2], where the y difference of the connecting node (server at [0, 0]) is greater then 1. This causes the constraints keeping the consistent grid pattern to fall apart and cause the unpredictable rendering we see.

Without using junctions, another way to fix this would be to replace edge 6 with lambda2:R -[6]-> L:dynamodb and keep the above change:

Which now moves s3 to position [1, 1] behind the scenes.

Obviously this behavior isn't ideal. Once I have more time I'll re-evaluate the options for layout engines to see if there's anything better but that probably won't happen until early in the summer.

In the meantime, I plan to make 2 changes to rectify the above issue:

1. Make the docs a lot more clear about this limitation. I'll make a few visual aids to avoid having to bring up the underlying coordinate system.
2. Add a check to detect jumps greater then 1 and throw an error.

[ggirard07]

One of the limitations of the underlying engine used for generating the layouts is that to enforce a clean grid pattern, each node needs to be no more then one "unit" away in X and Y direction.

This one is a massive limitation as of now, should be clearly stated in the documentation introduction