Blank Foam Graph - Cannot read properties of undefined (reading 'type'):389

[nwslnk]

Describe the bug

When a markdown doc contains a broken link, the graph panel sometimes fails to load.

For this tiny example repo, the graph seems to load / fail / load after a few tries. On a larger 'real' repo I cant seem to get it to load at all anymore.

Small Reproducible Example

https://github.com/nwslnk/foam-graph-example

Steps to Reproduce the Bug or Issue

1. Clone attached repo
2. disable all vscode plugins except foam 0.26.8
3. open foam graph

expected result

1. graph appears correctly

actual result

1. graph appears blank

2. closing and re-opening the graph multiple times, the graph loads

3. closing and re-opening the graph multiple times, the graph fails to load again

4. Remove the 'broken' link from the readme.md file (I guess this would be more correctly called a 'placeholder' in foam?)

expected result

1. graph appears correctly

actual result

1. graph appears correctly
2. closing and re-opening the graph multiple times, the graph appears correctly

Expected behavior

graph appears correctly

Screenshots or Videos

included in readme on linked repo

Operating System Version

macos

Visual Studio Code Version

1.99.0-insider Commit: 2c7a0283817355c81e1b106f34d911762950a4d9

Additional context

@riccardoferretti - Error references a recently updated line:
cad0c38#diff-a680ec0e1c2df2fe757d1f200ed2c855a1db94de9c0fe8643d2ab2ff8fae96a3R389

Prior to updating to 0.26.8 the graph appeared to load without issues (never noticed a failed load previously)

Also included (on repo) a copy of the extension host error that occurs when the graph view is clicked. Not sure if thats related or new though, just noticed it while going through output tabs.

(error aside, huge thanks to @riccardoferretti and everyone else from foam! i've been making the switch from obsidian and so far its been great!)

[nwslnk]

fwiw (i did look ;p), i realize there is another 'failed to load' report from 5 days ago 1435, but I dont see any details in it to confirm if it is the same cause or error. Since i was hammering away at notes yesterday without issue, an update came out today, and the error references code which was recently updated, I suspect these issues are unrelated. There are some other failed to open errors in the history as well, but they all appear to reference slightly different errors / causes / are marked as resolved.

[riccardoferretti]

Thanks for the detailed bug report! This makes life much easier, will look into it

[Tenormis]

@riccardoferretti Duplicated at #1436 (comment)

I submitted a Pull Request, could you please help me take a look when you have time.

[nwslnk]

@Tenormis, I built your branch and so far I've been unable to replicate using the example repo I shared. Switching between Tenormis:feat/tag-relationship and main I am able to replicate the error fairly easily.

re the type: 'tag' document concept - I played with it while I was on the branch and it seemed to keep working regardless of how weird a grouping I tried to make.

that said, as I was writing (to advocate for a 3rd way, i.e. implicit + explicit) I was playing around, and unless I'm mistaken, defining an explicit 'tag' grouping is actually already possible in the current mainline code (pic 3 below). Am I missing something?

The behavior in image 2 seems consistent with a normal hierarchical expectation, and image 3 appears to allow the explicit definition of relations as discussed in 1436 but without any code change. In that case, the remaining gap appears to be the ability to disable hierarchical linking (ie in favor of only explicit links), and the graph not rendering at all as discussed here?

^feature branch

^main with 'tags' commented

^main with 'tags' uncommented

fwiw, in both branches the debug log output is the same, except on main when it eventually throws the previously mentioned error.

[debug - 12:10:35 PM] Parsing:
"file:///Users/nwslnk/Workspace/foam-graph-example/README.md"
[debug - 12:10:35 PM] Result:
{
  "uri": {
    "scheme": "file",
    "authority": "",
    "path": "/Users/nwslnk/Workspace/foam-graph-example/README.md",
    "query": "",
    "fragment": ""
  },
  "type": "note",
  "properties": {},
  "title": "1. README.md",
  "sections": [
    {
      "label": "1. README.md",
      "range": {
        "start": {
          "line": 0,
          "character": 0
        },
        "end": {
          "line": 3,
          "character": 0
        }
      }
    },
    {
      "label": "md style",
      "range": {
        "start": {
          "line": 3,
          "character": 0
        },
        "end": {
          "line": 273,
          "character": 0
        }
      }
    },
    {
      "label": "wiki style",
      "range": {
        "start": {
          "line": 8,
          "character": 0
        },
        "end": {
          "line": 273,
          "character": 0
        }
      }
    }
  ],
  "tags": [],
  "aliases": [],
  "links": [
    {
      "type": "link",
      "rawText": "[somelink](./docs/ottobotto/ottobotto.md)",
      "range": {
        "start": {
          "line": 5,
          "character": 0
        },
        "end": {
          "line": 5,
          "character": 41
        }
      },
      "isEmbed": false
    },
    {
      "type": "link",
      "rawText": "[somelink](./docs/ottobotto2/ottobotto.md)",
      "range": {
        "start": {
          "line": 6,
          "character": 0
        },
        "end": {
          "line": 6,
          "character": 42
        }
      },
      "isEmbed": false
    },
    {
      "type": "wikilink",
      "rawText": "[[ottobotto]]",
      "range": {
        "start": {
          "line": 10,
          "character": 0
        },
        "end": {
          "line": 10,
          "character": 13
        }
      },
      "isEmbed": false
    },
    {
      "type": "wikilink",
      "rawText": "[[ottobotto2]]",
      "range": {
        "start": {
          "line": 11,
          "character": 0
        },
        "end": {
          "line": 11,
          "character": 14
        }
      },
      "isEmbed": false
    }
  ],
  "definitions": []
}
[debug - 12:10:36 PM] Updating parser cache
[debug - 12:10:41 PM] Graph updated in 0ms

@riccardoferretti I played with this for a while and couldnt seem to find exactly why model.graph.nodeInfo[link.source.id] was undefined sometimes and not others, but I suspect its related to updating the graph. Either way, maybe its hacky since I couldnt discover the source, but using optional chaining here seems to resolve the issue.

I've also updated my attached repo with the example tags and links in case it helps.

[Tenormis]

@nwslnk

The problem lies in the augmentGraphInfo function:

...
            graph.links.push({
              source: parent,
              target: label,
...
        graph.links.push({
          source: tag.label,
          target: node.id,
        });
...

---

The "hierarchical tags" is not a good idea. The tags in the document should be kept simple, such as a, b, c (instead of a/b/c, a/b, b/c ...), We can create a separate document of type tag to declare the relationships between the tags, like so:

• Structure:

  .
  ├── metadata/
  │   ├── java.md
  │   └── spring.md
  └── docs/
      ├── spring-cloud-gateway.md
      ├── spring-boot-core-features.md
      └── tomcat.md
  

• metadata/java.md:

  ---
  type: tag
  tags:
    - tomcat
    - spring
  ---

• metadata/spring.md:

  ---
  type: tag
  tags:
    - spring-cloud
    - spring-boot
  ---

• docs/spring-cloud-gateway.md:

  ---
  tags: spring-cloud
  ---
  
  Lorem ipsum dolor sit.

• docs/spring-boot-core-features.md:

  ---
  tags: spring-boot
  ---
  
  Lorem ipsum dolor sit.

• docs/tomcat.md:

  ---
  tags: tomcat
  ---
  
  Lorem ipsum dolor sit.

[riccardoferretti]

hi @nwslnk - I am unable to reproduce the issue using the sample repo. I have tried to open/close the graph multiple times and it always shows up correctly.

Thanks for the workaround, it helps locate the bug. I want to understand the actual source of the issue to properly fix it

@Tenormis great timing for your message, can you explain what the issue is in augmentGraphInfo?
Also, happy to hear your thoughts on the hierarchical tags, why do you think it's not a good idea?

[Tenormis]

@riccardoferretti Sorry, after further confirmation, the issue indeed does not lie in the graph.links.push code within the augmentGraphInfo method. I originally thought that the object being pushed should have its source and target fields as a {"id": ...} object (instead of a string), but in fact, this should not be a problem.

The real issue is with the .linkColor(link => getLinkColor(link, model)) method, where the link argument in the callback function is sometimes a string object and sometimes an {"id": ...} object. Modifying the getLinkColor method as follows should make it work properly:

   switch (getLinkState(link, model)) {
     case 'regular':
       if (
-        model.graph.nodeInfo[link.source.id].type === 'tag' &&
-        model.graph.nodeInfo[link.target.id].type === 'tag'
+        model.graph.nodeInfo[link.source.id || link.source].type === 'tag' &&
+        model.graph.nodeInfo[link.target.id || link.target].type === 'tag'
       ) {
         return getNodeTypeColor('tag', model);
       }

[nwslnk]

weird... I can confirm that link.source.id || link.source does prevent the issue as @Tenormis mentioned, and I can see where we come into the 'regular' case in getLinkColor() with link.source.id: undefined and link.source: "/Users/nwslnk/Workspace/foam-graph-example/README.md" which causes an error.

after digging around more, it definitely seem related to updating the graph / the cached list of files
i.e. if I start fresh

1. create a new folder (outside vscode)
2. open vscode
3. open the new folder
4. create a single readme.md file

# 1. README.md
===============

## md style

[[miff]]

5. Open dev tools
6. Open foam graph
7. Id expect this to open, in my case it fails the first time, and I see

8. Close graph, open again and I see

This renders if i resume from the break as expected
toggling links, tags, etc, back and forth (ie making edits to the link while stopped at the breakpoint, closing graph, re-opening) i can eventually flip flop between 'id' being defined or undefined. Sometimes I get stuck with it always working, other times it seems stuck undefined.
Creating a folder with a second test.md in it, then creating a link from readme.md --> test/test.md and opening graph (successfully), closing graph, deleting the test folder (and test.md), and then opening graph seems to result in 'id' undefined as well, and seems a little more replicable on my system if that helps.

point of the ramble is, id being defined seems related to a cache of files and links and whether the graph is being forced to update.

I guess, end of the day aside from obsessing over the root cause, this issue is all related to coloring the links between 'tag' nodes and (so far as I can see) isnt immediately causing other issues... so maybe it doesnt really matter?

re

The "hierarchical tags" is not a good idea. The tags in the document should be kept simple, such as a, b, c (instead of a/b/c, a/b, b/c ...), We can create a separate document of type tag to declare the relationships between the tags, like so:

I guess I'll have to agree to disagree (just my opinion, not worth much I know :) ) I see your point, that automatic hierarchy may not be ideal in some cases, and from what I can see, the functionality described of creating a type: tag md file with a list of tags: -tag1 -tag2 is already there, in addition to #tag1/tag2. The automatic grouping feels quite useful from my pov, whereas needing to create all groupings manually feels unlikely to happen for me. I dont see an obvious case of how the automatic hierarchy would be harmful, but I understand your example where it could be undesirable. that said, as you showed with your example, could the simple alternative be to create 'hierarchical' tags with '-' instead of '/' to avoid the automatic grouping in favor of manual definition?

[riccardoferretti]

Thanks for the deeper dive. Unfortunately also with your latest steps I haven't been able to reproduce it.
This is surprising, source and target should always be strings, and I am not sure from the code where it could happen that we are doing the wrong assignment.
The connection in your example is between notes, not tags; the code that creates those links is in dataviz.ts
Can you show me what object they are? (expand them in the watch panel)

[nwslnk]

@riccardoferretti surely :)

setup

test.md is an empty file

debug

devtools after returning from debug

---

After the working example above, I tried to get back to a failing example to capture the same. I was unable (and tbh, I dont know if its ever been the case) to replicate with ONLY type: note nodes, I think its always been where its a placeholder or a missing file. Looking back at the history I think thats true, and in the example repo where I have a md style link to a missing file (rather than just the wikilink style). Apologies if this wasnt clear; the steps reference removing the 'broken link', and deleting files and reloading the graph, but I hadnt explicitly thought about / focused on the fact that at least one half of each link would have been either a placeholder, a link to a previously existing file, or a tag.

After staring at this for a while, I guess what you were after was just this (I should have realized and posted sooner instead of continuing to chase where/when id gets set):

i.e. vx, vy, x, y dont exist initially, neither do controlPoints, or indexColor, they appear to be added as the graph builds? and somewhere in that loop link.source.id becomes populated? And somehow i'm hitting .linkColor before that happens sometimes?

I if I break graph.js e.g. on LN193, link.source.id is always undefined at the end (at least every time i tried, which was many many times). But if i break on 389 only, its far more difficult to cause.

[riccardoferretti]

Thanks for the detailed report, I think I know what's going on.
Basically we are looking at different objects.
getLinkColor is called by graph(elem).[...].linkColor(link => .... The link object is not the same object as in graph.links - specifically the items in graph.links are strings (which represent IDs), whereas the link param in linkColor is a force-graph link object, which includes the id and some location information.

So, that explains the difference you are seeing (you can see this at play in this getLinkState:

fLink.source === link.source.id && fLink.target === link.target.id

That also explains the difference between LN193 and LN389 you saw.

---

from @Tenormis 's comment:

The real issue is with the .linkColor(link => getLinkColor(link, model)) method, where the link argument in the callback function is sometimes a string object and sometimes an {"id": ...} object

That should never be the case. The link in getLinkColor should always have an id field.
If that's not the case please let me know.

---

Unfortunately all of this is useful to get better context, but not to solve the problem (again, I can't reproduce it).
Reading back the various comments, the problem doesn't seem to have ever been the ID of the link, but with a missing node in nodeInfo, or at least that's my feeling now (is it failing when looking at .type on undefined?).
It would be helpful to know the exception it fails with, and a sort of memory dump at that moment.
Of course it would be great if I could reproduce it 😅

Thanks for helping "remote debug" this issue.

[riccardoferretti]

I should add, a possible workaround could be to simply match the shapes of the two objects (basically the items of graph.links could have an id instead of simply being strings). But again, I am not very comfortable not knowing what the actual issue is and just patching things up.

[Tenormis]

The discussion about "Hierarchical Tags" and "Tag Relationship Graph" has shifted to Discussion, looking forward to your comments. @nwslnk @riccardoferretti

[Tenormis]

That should never be the case. The link in getLinkColor should always have an id field.
If that's not the case please let me know.

@riccardoferretti But it is indeed:

[riccardoferretti]

Thanks for reporting that @Tenormis.
Looking at the force-graph types here, link.source and link.target can indeed be either object or string (although I don't understand the mechanism).

So I am implementing a workaround to take that into account, although I don't love not knowing the exact cause of the issue. At least this will be sorted.

@Tenormis - can I ask you to create a small repo to reproduce this state? I can't manage to do it locally and it would be super helpful to properly understand what is going on.
Also, I have just released the new version (0.26.9) with the workaround, can you let me know if the issue is still present?

Thanks everyone!

[Tenormis]

File Structure:

dir1/
└── doc1.md
dir2/
└── doc2.md

doc1.md:

---
type: doc1
---
[text](../dir2/doc2.md#1-title-with-中文)

doc2.md:

---
tags: docs
---
## 1. Title with 中文

For the small project, I currently cannot achieve a 100% reproduction rate. The above minimal case has about a 10-20% chance of being reproduced. Remember to clear the cache and reopen the project, and try several times.
@riccardoferretti

[nwslnk]

thanks @riccardoferretti @Tenormis! fwiw I finally had a chance to update to 0.26.10 and no longer encounter the graph issue on either my main repo or the previously shared demo repo :)

happy to mark this issue closed unless there is ongoing investigation re comment from @Tenormis on the 30th.

thanks again!