Skip to content

Flush editor execution before starting sketches - #13639

Draft
JordanNoone wants to merge 1 commit into
mainfrom
codex/fix-editor-sketch-sync-race
Draft

Flush editor execution before starting sketches#13639
JordanNoone wants to merge 1 commit into
mainfrom
codex/fix-editor-sketch-sync-race

Conversation

@JordanNoone

Copy link
Copy Markdown
Contributor

Fixes #13229.

What changed

  • Teach the shared deferred callback helper to expose an awaitable flush() that runs pending work immediately and waits for work already in flight.
  • Expose that boundary through KclManager.flushPendingEditorExecution().
  • Flush direct editor execution before the modeling machine reads the AST or enters sketch mode.

This keeps the normal one-second editor debounce unchanged. The only new ordering constraint is at sketch entry, where the current editor program and Rust scene graph must agree before a sketch ObjectId is created.

Why

The preserved QCC replay for #13229 reproduces the fast sequence 3/3 times and passes a human-paced control 2/2 times. The direct editor edit schedules a debounced settings-only execution, but Start Sketch can create ObjectId(1) first. When the queued execution finally runs, it replaces the Rust scene graph; the next rectangle segment then targets the stale sketch id and fails with Sketch not found: ObjectId(1).

Two deterministic KclManager regressions cover both sides of that ordering boundary: flushing timer-pending editor work and waiting for an editor execution that has already started. They failed before the implementation because the synchronization boundary did not exist; after the change the focused integration suite passes 37/37. The focused utility suite passes 193/193, and TypeScript plus ESLint checks pass.

I also checked draft PR #13605 at head a02bdd3997855e3509e93f03c290eb8d9e324017 as a negative control. It changes modifyAst selection preservation only and does not touch the editor debounce, KclManager, the modeling machine, or Rust scene lifecycle, so it does not cover #13229.

GUI coverage and risk

The QCC adapter discovered the targeted replay against exact origin/main (d2e2a8a5c56024c60d00f11b3a9efd4933aa47a6) and against #13605. A live control replay stopped before browser launch because approved first-party QA authentication was unavailable in this environment. Per the QCC control-first contract, I did not run or claim a fixed GUI replay, so this PR has no new screenshot or trace artifact.

Risk is localized: Start Sketch may now wait for the current direct editor execution instead of racing it. Deferred executions elsewhere retain their existing timer behavior. The remaining uncertainty is visual end-to-end confirmation on an authenticated preview.

@vercel

vercel Bot commented Sep 4, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
modeling-app Ready Ready Preview Sep 4, 2026 1:45am UTC

Request Review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Codex fuzzer: Starting a sketch within the editor debounce leaves a stale sketch ObjectId

1 participant