[BUG] Typing scrambles and the cursor jumps to line 1 in the query editor on large schemas

[nycjay]

Description

On a connection with a large schema, typing in the query editor drops and reorders characters, and the cursor jumps back to the start of the document. It gets bad enough that you can't write a query normally. It does not happen on the small sample connections, so it is easy to miss until you connect to a real database with a few hundred tables.

Steps to Reproduce

1. Connect to a database with a large schema. I reproduced it on SQLite with 400 tables, but any provider with a large schema does it.
2. Open a query tab and click into the editor.
3. Type a sentence at a normal pace, for example SELECT id FROM entity_0001 WHERE owner_id = 42 ORDER BY created_at DESC.
4. Watch characters land out of order and the cursor snap to line 1.

Expected Behavior

Each character is inserted at the caret and the caret moves forward one position, regardless of schema size.

Actual Behavior

Characters are dropped and reordered as you type, and the caret resets to the top. Typing the string above produced SEETi RMett_01WEEonri 2ODRB rae_tDSC in the buffer instead of the text I typed. The same typing into a small-schema connection is fine, as it typing very slowly.

Screenshots

N/A.

Environment

Please provide the following information:

• LibreDB Studio Version: 0.15.0
• Browser: Chrome
• OS: macOS 26.6.2
• Node.js/Bun Version: Bun 1.4.0
• Database Type: SQLite
• Database Version: SQLite 3 (bundled)

Additional Context

The editor is @monaco-editor/react 4.7.0, running under Next.js 16.3.4 with Turbopack. The schema size is an amplifier, not the cause. A larger schema makes the surrounding UI do more render work per keystroke, which widens the timing window the bug depends on, so it shows up on large-schema connections and not on the small samples.

Possible Solution

QueryEditor renders Monaco as a controlled component with value={value}, and that prop is fed from onContentChange on every keystroke. Studio writes each keystroke into currentTab.query, which flows straight back in as value. @monaco-editor/react runs an executeEdits over the full model range whenever the value prop changes and differs from the buffer. When a keystroke lands in the model between the state update and the re-render, the prop arrives one keystroke stale, the full-range edit rewrites the whole buffer, and the caret resets to (1,1).

One fix is to stop driving the buffer from the value prop on the keystroke path. Make the editor uncontrolled with defaultValue, and route external changes such as tab switch, Format, and Clear through a single guarded effect. I have this working and confirmed on the 400-table setup: typing lands verbatim, the caret only moves forward, and there are no full-buffer rewrites during typing. I will open a PR against this issue.

Logs

No console errors. The failure is a silent buffer rewrite, not a thrown error.

[nycjay]

Worth noting how this relates to the other large-schema reports, since they share a trigger but not a cause.

This is not the same bug as #765 (Oracle eager getSchema() freezing the UI on connect). That one is about loading a large schema: the full-owner introspection runs on connect, exhausts the heap, and blocks rendering until it finishes. #808 happens after the schema is already loaded and sitting in memory. The editor works fine, and then typing corrupts the buffer because a keystroke races the controlled value prop. A large schema is the amplifier in both, but the mechanisms are in different layers. #765 is data loading, #808 is a per-keystroke render race in the editor.

The lazy/two-phase object tree from #789 would cut the per-keystroke render work that makes #808 easy to hit, so landing that epic should make this harder to trigger. It would not fix the underlying race though, which is why I am treating #808 as its own fix rather than folding it into either.