On New App Builder: Builder thread strands uncommitted edits — can't publish

💬 App Building
,
1

Title: Builder thread strands uncommitted edits — can't publish

Severity: High — looks like lost work, no UI recovery, and the only workaround burns AI credits.

Environment: Retool React apps (Beta), driven via the MCP server (retool_create_or_append_react_app_thread_message), environmentName: production. Likely reproducible from in-editor Chat too.

Repro (minimal):

  1. Start a builder thread that edits several files.
  2. The agent runs an execute_backend_code test-run; the sandbox runtime drops mid-run, before the thread commits.
  3. Result: edits live in the working tree (they render in Preview, show in the Code tab, and retool_read_react_app_files returns them with the generationId) — but there's no commit on the branch.

Diagnostic signature (exact signals):

  • retool_get_react_app_thread_activity_status → state: "ACTIVE" and liveConnectionAvailable: false (active but no runtime).
  • retool_cancel_react_app_thread_activity / retool_respond_to_react_app_thread_review → generation_not_found.
  • Browser Publish: grayed out, "There are no new changes to publish."
  • retool_publish_react_app → "No commits found on this thread branch. Save or generate changes before publishing."
  • Code tab is read-only, so I can't hand-edit a file to force a dirty state either.

Expected: Working-tree changes should be recoverable/publishable — auto-commit when work lands, or a "Keep/commit changes" action — and Publish should reflect the working copy, not say "no changes" when it clearly differs from main.

Actual: Work is visible but unpublishable, with no recovery path in the UI.

Workaround (only thing that worked): send the same thread (reuse the generationId) another message telling it to make a real file write and commit. That produced a commit, which un-grayed Publish and let retool_publish_react_app succeed.

Likely root cause / where to look: the thread seems to commit only on successful turn completion; a runtime drop mid-execute_backend_code skips that commit, leaving the sandbox working tree ahead of the branch with no commit and no UI affordance to reconcile. Fixes: (1) harden execute_backend_code so a test-run can't strand the runtime; (2) make landed edits durable — auto-commit or expose a commit/keep action — and fix the "no changes to publish" state to reflect the actual working copy.

4

Thanks for documenting and flagging this, @Peter_Kellner! For context, it looks like the sandbox was initially killed after waiting an hour for a response to a confirmExecuteCode HITL prompt. Because the turn never finished, it didn't result in a corresponding commit.

That said, I'd expect any previous commits in the same thread to be publishable upon reloading the snapshot. I know that you may not be actively working in Retool anymore, but can you confirm that you'd made publishable commits earlier in the same thread? And that the normally editable raw code files were specifically in a read-only state?