ENG-1475 Export relations to imported nodes

[maparent]

https://linear.app/discourse-graphs/issue/ENG-1475/export-relations-to-imported-nodes

https://www.loom.com/share/527b312dca4f441083f9ae25987e5f57

Code note: the main work was to send the original node's koi identifier in upsertConcept, and have that function resolve the identifier to the original node.

---

[linear]

ENG-1475 Export relations to imported nodes

[supabase]

Updates to Preview Branch (eng-1475-export-relations-to-imported-nodes) ↗︎

Deployments	Status	Updated
Database	✅	Wed, 04 Mar 2026 17:15:11 UTC
Services	✅	Wed, 04 Mar 2026 17:15:11 UTC
APIs	✅	Wed, 04 Mar 2026 17:15:11 UTC

Tasks are run on every commit but only new migration files are pushed.
Close and reopen this PR if you want to apply changes from existing seed or migration files.

Tasks	Status	Updated
Configurations	✅	Wed, 04 Mar 2026 17:15:11 UTC
Migrations	✅	Wed, 04 Mar 2026 17:15:11 UTC
Seeding	✅	Wed, 04 Mar 2026 17:15:12 UTC
Edge Functions	✅	Wed, 04 Mar 2026 17:15:15 UTC

---

View logs for this Workflow Run ↗︎.
Learn more about Supabase for Git ↗︎.

[devin-ai-integration]

Devin Review found 2 potential issues.

View 8 additional findings in Devin Review.

[devin-ai-integration]

Devin Review found 2 new potential issues.

🐛 1 issue in files not directly in the diff

🐛 Missing legacy importedFromSpaceUri check in shouldSyncFile allows imported files to be synced (apps/obsidian/src/utils/fileChangeListener.ts:101-103)

After the migration from importedFromSpaceUri to importedFromRid, shouldSyncFile only checks frontmatter?.importedFromRid but does NOT check the legacy frontmatter?.importedFromSpaceUri. The refactored collectDiscourseNodesFromVault in getDiscourseNodes.ts:32-38 correctly checks both fields:

if (
  (frontmatter.importedFromRid || frontmatter.importedFromSpaceUri) &&
  includeImported !== true
) { continue; }

Root Cause and Impact

The FileChangeListener is initialized immediately (apps/obsidian/src/index.ts:56-57) via this.fileChangeListener.initialize(), while migrateImportedFromFrontMatter runs asynchronously inside the fire-and-forget void initializeSupabaseSync(this) call at apps/obsidian/src/index.ts:47. During the migration window (or if migration fails), files that still have only importedFromSpaceUri in their frontmatter will pass shouldSyncFile, be queued, and eventually be synced to Supabase as locally-created nodes. This could create duplicate concepts or corrupt data in the remote database.

View 12 additional findings in Devin Review.

[devin-ai-integration]

🔴 Missing legacy importedFromSpaceUri check in collectDiscourseNodesFromPaths allows imported files to be synced

Same root cause as in shouldSyncFile: collectDiscourseNodesFromPaths only checks frontmatter.importedFromRid but not the legacy frontmatter.importedFromSpaceUri. The refactored collectDiscourseNodesFromVault at apps/obsidian/src/utils/getDiscourseNodes.ts:32-38 correctly checks both fields, but this function was not updated consistently.

Root Cause and Impact

This function is used by syncDiscourseNodeChanges (called from FileChangeListener). During the migration window or if migration fails, any file change event on a file that still has only the legacy importedFromSpaceUri will pass through both shouldSyncFile and collectDiscourseNodesFromPaths guards, causing the imported node to be synced to Supabase as a locally-created node. This is a second guard that should also check the legacy field for defense-in-depth.

(Refers to lines 717-720)

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Missing legacy importedFromSpaceUri check in shouldSyncFile allows imported files to be synced (apps/obsidian/src/utils/fileChangeListener.ts:101-103)

After the migration from importedFromSpaceUri to importedFromRid, shouldSyncFile only checks frontmatter?.importedFromRid but does NOT check the legacy frontmatter?.importedFromSpaceUri. The refactored collectDiscourseNodesFromVault in getDiscourseNodes.ts:32-38 correctly checks both fields:

if (
  (frontmatter.importedFromRid || frontmatter.importedFromSpaceUri) &&
  includeImported !== true
) { continue; }

Root Cause and Impact

The FileChangeListener is initialized immediately (apps/obsidian/src/index.ts:56-57) via this.fileChangeListener.initialize(), while migrateImportedFromFrontMatter runs asynchronously inside the fire-and-forget void initializeSupabaseSync(this) call at apps/obsidian/src/index.ts:47. During the migration window (or if migration fails), files that still have only importedFromSpaceUri in their frontmatter will pass shouldSyncFile, be queued, and eventually be synced to Supabase as locally-created nodes. This could create duplicate concepts or corrupt data in the remote database.

View 18 additional findings in Devin Review.

[devin-ai-integration]

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Missing legacy importedFromSpaceUri check in shouldSyncFile allows imported files to be synced (apps/obsidian/src/utils/fileChangeListener.ts:101-103)

After the migration from importedFromSpaceUri to importedFromRid, shouldSyncFile only checks frontmatter?.importedFromRid but does NOT check the legacy frontmatter?.importedFromSpaceUri. The refactored collectDiscourseNodesFromVault in getDiscourseNodes.ts:32-38 correctly checks both fields:

if (
  (frontmatter.importedFromRid || frontmatter.importedFromSpaceUri) &&
  includeImported !== true
) { continue; }

Root Cause and Impact

The FileChangeListener is initialized immediately (apps/obsidian/src/index.ts:56-57) via this.fileChangeListener.initialize(), while migrateImportedFromFrontMatter runs asynchronously inside the fire-and-forget void initializeSupabaseSync(this) call at apps/obsidian/src/index.ts:47. During the migration window (or if migration fails), files that still have only importedFromSpaceUri in their frontmatter will pass shouldSyncFile, be queued, and eventually be synced to Supabase as locally-created nodes. This could create duplicate concepts or corrupt data in the remote database.

View 18 additional findings in Devin Review.

[trangdoan982]

i accidentally found a case where this might fail:

• if we clean up the orphaned node, then the stale relation instance won't be able to resolve to any db id -> cause this function to return null -> cause concept.reference_content -> violate non-null constraints -> unable to upsert ANY concepts.

i discovered this bug after having ran supbase db reset, keeping the vault the same. this means that locally there will be old imported files with frontmatter field importFromRid, that we can't resolve in db. Hence, i received this error:
VM209 plugin:@discou…raph/obsidian:55074 Initial sync failed: Error: upsert_concepts failed: {
"code": "23502",
"details": null,
"hint": null,
"message": "null value in column "reference_content" of relation "Concept" violates not-null constraint"
}

this shouldn't be blocking any syncing operation

[maparent]

Ok, this is a bit of a headache. I corrected the function to allow partial failures; but it means we cannot use the lastSync time anymore!
I think... we need to look at error values, i.e. negative Ids returned by upsertConcept, and possibly remove the offending node/relations. Let's discuss 1-1.

[maparent]

Leaving a trail: we will think about error handling in another PR (ENG-1510.)
The issue of lastSync time may not be as pressing, since the nodes with an error probably cannot be inserted anyway.

[devin-ai-integration]

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Missing legacy importedFromSpaceUri check in shouldSyncFile allows imported files to be synced (apps/obsidian/src/utils/fileChangeListener.ts:101-103)

After the migration from importedFromSpaceUri to importedFromRid, shouldSyncFile only checks frontmatter?.importedFromRid but does NOT check the legacy frontmatter?.importedFromSpaceUri. The refactored collectDiscourseNodesFromVault in getDiscourseNodes.ts:32-38 correctly checks both fields:

if (
  (frontmatter.importedFromRid || frontmatter.importedFromSpaceUri) &&
  includeImported !== true
) { continue; }

Root Cause and Impact

The FileChangeListener is initialized immediately (apps/obsidian/src/index.ts:56-57) via this.fileChangeListener.initialize(), while migrateImportedFromFrontMatter runs asynchronously inside the fire-and-forget void initializeSupabaseSync(this) call at apps/obsidian/src/index.ts:47. During the migration window (or if migration fails), files that still have only importedFromSpaceUri in their frontmatter will pass shouldSyncFile, be queued, and eventually be synced to Supabase as locally-created nodes. This could create duplicate concepts or corrupt data in the remote database.

View 18 additional findings in Devin Review.

[devin-ai-integration]

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Missing legacy importedFromSpaceUri check in shouldSyncFile allows imported files to be synced (apps/obsidian/src/utils/fileChangeListener.ts:101-103)

After the migration from importedFromSpaceUri to importedFromRid, shouldSyncFile only checks frontmatter?.importedFromRid but does NOT check the legacy frontmatter?.importedFromSpaceUri. The refactored collectDiscourseNodesFromVault in getDiscourseNodes.ts:32-38 correctly checks both fields:

if (
  (frontmatter.importedFromRid || frontmatter.importedFromSpaceUri) &&
  includeImported !== true
) { continue; }

Root Cause and Impact

The FileChangeListener is initialized immediately (apps/obsidian/src/index.ts:56-57) via this.fileChangeListener.initialize(), while migrateImportedFromFrontMatter runs asynchronously inside the fire-and-forget void initializeSupabaseSync(this) call at apps/obsidian/src/index.ts:47. During the migration window (or if migration fails), files that still have only importedFromSpaceUri in their frontmatter will pass shouldSyncFile, be queued, and eventually be synced to Supabase as locally-created nodes. This could create duplicate concepts or corrupt data in the remote database.

View 19 additional findings in Devin Review.

[devin-ai-integration]

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Missing legacy importedFromSpaceUri check in shouldSyncFile allows imported files to be synced (apps/obsidian/src/utils/fileChangeListener.ts:101-103)

After the migration from importedFromSpaceUri to importedFromRid, shouldSyncFile only checks frontmatter?.importedFromRid but does NOT check the legacy frontmatter?.importedFromSpaceUri. The refactored collectDiscourseNodesFromVault in getDiscourseNodes.ts:32-38 correctly checks both fields:

if (
  (frontmatter.importedFromRid || frontmatter.importedFromSpaceUri) &&
  includeImported !== true
) { continue; }

Root Cause and Impact

The FileChangeListener is initialized immediately (apps/obsidian/src/index.ts:56-57) via this.fileChangeListener.initialize(), while migrateImportedFromFrontMatter runs asynchronously inside the fire-and-forget void initializeSupabaseSync(this) call at apps/obsidian/src/index.ts:47. During the migration window (or if migration fails), files that still have only importedFromSpaceUri in their frontmatter will pass shouldSyncFile, be queued, and eventually be synced to Supabase as locally-created nodes. This could create duplicate concepts or corrupt data in the remote database.

View 18 additional findings in Devin Review.