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 2 new potential issues.

View 53 additional findings in Devin Review.

[devin-ai-integration]

🟡 Legacy settings path bypasses Zod validation via unsafe as cast

When the "Use new settings store" feature flag is disabled (the default), bulkReadSettings() returns readAllLegacyGlobalSettings() as GlobalSettings and readAllLegacyPersonalSettings() as PersonalSettings without running the data through Zod validation. The new-store path at lines 889-890 correctly validates via GlobalSettingsSchema.parse() / PersonalSettingsSchema.parse(), which would catch type mismatches (e.g., NaN from parseInt for Max filename length, or unexpected shapes from Relations). The legacy path silently passes through whatever the readers produce, potentially causing runtime errors in components that expect validated types.

Example: NaN propagation from legacy export reader

getUidAndIntSetting in apps/roam/src/utils/getExportSettings.ts:49 uses parseInt(...) which can return NaN. The legacy global reader at accessors.ts:423 uses ?? DEFAULT but NaN ?? 64 evaluates to NaN (not null/undefined). The as GlobalSettings cast masks this, while GlobalSettingsSchema.parse() would coerce or reject it.

Prompt for agents

The legacy fallback path in bulkReadSettings() casts readAllLegacyGlobalSettings() and readAllLegacyPersonalSettings() to GlobalSettings / PersonalSettings without Zod validation. The new-store path at lines 889-890 correctly uses .parse(). To fix, run the legacy results through the same Zod schemas: GlobalSettingsSchema.parse(readAllLegacyGlobalSettings()) and PersonalSettingsSchema.parse(readAllLegacyPersonalSettings()). This ensures both code paths produce validated, schema-conformant data and prevents malformed legacy data from propagating as unexpected types.

---

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

[devin-ai-integration]

🟡 Nested debounce in BaseTextPanel can skip block-props setter for intermediate values

The handleChange function stores the inner setTimeout ID in the same debounceRef.current as the outer one. If the user types a value, the outer timeout fires (calling syncToBlock), and then the user types again within the 100ms inner window, clearTimeout(debounceRef.current) cancels only the inner timeout — meaning syncToBlock already wrote the intermediate value to the Roam block, but the block-props setter and refreshConfigTree never fire for that value. This creates a transient inconsistency between the Roam block tree and the block-props store until the next change settles. While not data-losing (the final value eventually syncs both), it can cause stale reads from the block-props store during the window.

Sequence that triggers the inconsistency

1. User types "A" → outer timeout starts (250ms)
2. Outer fires → syncToBlock("A") writes to Roam, inner timeout (100ms) starts, stored in debounceRef
3. User types "AB" within 100ms → clearTimeout clears inner, new outer starts
4. Result: Roam block has "A" written but setter/refreshConfigTree never ran for "A"
5. Eventually "AB" settles and both stores sync

Prompt for agents

In BaseTextPanel's handleChange, the nested setTimeout pattern shares debounceRef.current for both the outer and inner timeouts, which means a new keystroke during the inner 100ms window cancels the block-props setter but not the already-executed syncToBlock. Consider using a separate ref for the inner timeout so both can be independently cancelled on cleanup and on new keystrokes. Alternatively, collapse the two timeouts into a single debounced callback that does syncToBlock, refreshConfigTree, and setter in sequence after the debounce settles.

---

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