ENG-1454: Base getter() task

[sid597]

#DO NOT MERGE - until all the other prs are

---

[linear]

ENG-1454 Base `getter()` task

[supabase]

This pull request has been ignored for the connected project zytfjzqyijgagqxrzbmz because there are no changes detected in packages/database/supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 7 additional findings in Devin Review.

[devin-ai-integration]

🟡 Changed QuerySettingsSchema defaults corrupt legacy-path fallbacks

The QuerySettingsSchema defaults were changed ("Hide query metadata" from false → true, "Query pages" from [] → ["discourse-graph/queries/*"]). These new defaults propagate into DEFAULT_PERSONAL_SETTINGS (computed at module load via PersonalSettingsSchema.parse({}) at accessors.ts:165), which is then used as the fallback value in getLegacyPersonalSetting().

Root cause and impact

In getLegacyPersonalSetting (accessors.ts:212-251), when a mapped key is found, the fallback default is read from DEFAULT_PERSONAL_SETTINGS:

return getSetting<unknown>(
  mappedOldKey,
  readPathValue(DEFAULT_PERSONAL_SETTINGS, keys),
);

For keys = ["Query", "Hide query metadata"], this resolves to getSetting("hide-metadata", true). If the user has never explicitly set this value, getSetting returns true (the new default) instead of false (the old default). The intent of the legacy path is backward compatibility with the old system, but the fallback now returns different values than the old system provided.

Concretely:

• Users who never explicitly set "Hide query metadata" will see query metadata hidden when it was previously shown.
• Users who never explicitly set "Query pages" will get ["discourse-graph/queries/*"] instead of [].

The getters aren't called yet (being built in this PR), but when they are wired up, the legacy path will silently change behavior for users who haven't explicitly configured these settings.

---

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

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 24 additional findings in Devin Review.

[devin-ai-integration]

🔴 Hyde search defaults changed from true to false, degrading suggestive mode search quality

In hyde.ts, the old code read shouldGrabFromReferencedPages and shouldGrabParentChildContext from phantom extensionAPI keys (context-grab-from-referenced-pages, context-grab-parent-child-context) that were never written anywhere in the codebase. Since the keys never existed, extensionAPI.settings.get(...) always returned undefined, and the ?? true fallback ensured both flags were always true. The new code reads from the global accessor with a ?? false fallback. The schema defaults for "Include current page relations" and "Include parent and child blocks" are also false. This means for users who never explicitly configured these settings (which is everyone, since the UI writes to different keys), the behavior silently changes from always including referenced pages and parent/child blocks in the search to never including them. This degrades suggestive mode hyde search results.

---

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

[devin-ai-integration]

Devin Review found 3 new potential issues.

View 43 additional findings in Devin Review.

[devin-ai-integration]

🟡 Inverted fold/unfold logic: isOpen state and block CRUD are backwards

In toggleFoldedState, when isOpen is true (section is currently open/expanded), the code calls setIsOpen(false) and deletes the "Folded" block — meaning it unfolds by removing the folded marker. But when isOpen is false, it calls setIsOpen(true) and creates a "Folded" block. This means the isOpen React state tracks whether the section is collapsed (folded), not whether it is open. The newFolded value at LeftSidebarView.tsx:130 is computed as !isOpen, so when isOpen=true (collapsed/folded), newFolded=false — and this is the value written to the new settings store. However, the old-system block CRUD on lines 132-148 does the opposite: when isOpen=true it deletes the Folded block (setting folded=false), and when isOpen=false it creates the Folded block (setting folded=true). So both systems agree on the final folded value.

The actual bug is that the newFolded value written to the new settings store at lines 150-166 is !isOpen, but the old-system block operations establish that isOpen=true means "currently folded" (since the Folded block exists). When the section is currently folded (isOpen=true), newFolded = !true = false → correct (we're unfolding). When the section is currently expanded (isOpen=false), newFolded = !false = true → correct (we're folding). So the value is actually correct.

However, looking at PersonalSectionItem at line 223, isOpen is initialized from !!section.settings?.folded.value, meaning isOpen=true when folded=true. This means isOpen actually represents "is folded", not "is open". The Collapse isOpen={isOpen} at line 262 will then show content when folded=true and hide content when folded=false — which is the opposite of expected behavior. The section is shown expanded when the folded flag is true, and collapsed when it's false.

(Refers to lines 223-224)

---

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

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 45 additional findings in Devin Review.

[devin-ai-integration]

🔴 getLegacyRelationsSetting reads relations from the block-props settings page instead of the legacy config page

getLegacyRelationsSetting at apps/roam/src/components/settings/utils/accessors.ts:284 reads a grammar > relations subtree from DG_BLOCK_PROP_SETTINGS_PAGE_TITLE (the new block-props settings page). However, the legacy grammar/relations tree actually lives on DISCOURSE_CONFIG_PAGE_TITLE ("roam/js/discourse-graph"), as shown by getDiscourseRelations.ts reading from discourseConfigRef.tree. Since the block-props settings page has no grammar subtree, getSubTree returns empty children, relationNodes is empty, and the function falls back to DEFAULT_GLOBAL_SETTINGS.Relations.

This causes two downstream problems:

1. Migration data loss: migrateGraphLevel → readAllLegacyGlobalSettings() → getLegacyGlobalSetting(["Relations"]) reads defaults instead of actual legacy relations, then overwrites correctly-initialized block props (init.ts + reconcileRelationKeys) with those defaults.
2. Spurious dual-read warnings: When isNewSettingsStoreEnabled() is true, getGlobalSetting(["Relations", ...]) compares block-props values against defaults (not actual legacy data), generating incorrect mismatch warnings.

Expected fix

Read from `discourseConfigRef.tree` (or `DISCOURSE_CONFIG_PAGE_TITLE`) instead of `DG_BLOCK_PROP_SETTINGS_PAGE_TITLE`:

const getLegacyRelationsSetting = (): Record<string, unknown> => {
  const tree = discourseConfigRef.tree;
  const grammarChildren = getSubTree({ tree, key: "grammar" }).children;
  const relationNodes = getSubTree({ tree: grammarChildren, key: "relations" }).children;
  ...
};

Prompt for agents

In apps/roam/src/components/settings/utils/accessors.ts, the function getLegacyRelationsSetting (starting around line 283) reads from DG_BLOCK_PROP_SETTINGS_PAGE_TITLE, which is the new block-props settings page. It should instead read from the legacy discourse config tree where the grammar/relations data actually lives.

Change:
  const settingsUid = getPageUidByPageTitle(DG_BLOCK_PROP_SETTINGS_PAGE_TITLE);
  if (!settingsUid) return DEFAULT_GLOBAL_SETTINGS.Relations;
  const configTree = getBasicTreeByParentUid(settingsUid);

To:
  const configTree = discourseConfigRef.tree;
  if (!configTree || configTree.length === 0) return DEFAULT_GLOBAL_SETTINGS.Relations;

This ensures the legacy relations are read from 'roam/js/discourse-graph' (via discourseConfigRef.tree) where they are actually stored, matching how getDiscourseRelations.ts reads them.

---

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