[URGENT/CRITICAL] 100% Reproducible BUG: Permanent Project Corruption and VFS Deadlock when toggling Web Worker in App Builder

Google AI Studio
,
1

[URGENT/CRITICAL] 100% Reproducible: Permanent Project Corruption and VFS Deadlock when toggling Web Worker in App Builder

1. Summary

A critical architectural flaw exists in the AI Studio App Builder preview runner. Switching an app’s implementation between “Main Thread” and “Web Worker” mode (involving worker.js) causes the preview sandbox to enter a permanent, unrecoverable “Broken State.” Once the error “Failed to load the app. Try reloading it.” is triggered, it becomes a terminal state. There is NO workaround or recovery path available to the user. Neither manual reloads, browser hard refreshes, clearing cache, nor clicking the project restart button can restore functionality. The affected Project ID is rendered permanently unusable, effectively resulting in the total loss of the project and all associated development progress.

This is a major blocker for performance-critical projects, such as Markdown-to-PDF generators, where offloading heavy PDF serialization to a Web Worker is a standard architectural requirement to prevent UI freezing.

2. Environment

  • Platform: Google AI Studio (Web Interface)

  • Feature: App Builder (Preview Pane)

  • Model: Gemini 3 Pro

  • Build Tool: Integrated Vite-based Sandbox

  • Reproducibility: 100% (Tested across multiple independent sessions)

  • Persistence: Fatal/Terminal. The corruption persists at the backend/session level.

3. Steps to Reproduce

  1. Scenario A (Non-Worker to Worker):

    • Start a project (e.g., a Markdown-to-PDF tool) on the Main Thread.

    • Once the preview is active, ask the AI to refactor the generation logic into a Web Worker (worker.js).

    • Result: The sandbox fails to resolve the path, and the preview pane crashes.

  2. Scenario B (Worker to Non-Worker - The Fatal Path):

    • Start a new project explicitly requesting a Web Worker architecture from the first prompt.

    • Once the app is running, ask the AI to switch back to Main Thread mode (removing the worker).

    • Result: The preview pane immediately crashes with “Failed to load the app.”

  3. Verification of Terminal State (The “Point of No Return”):

    • Click the “Reload” button in the preview pane: Persistent Failure.

    • Hard refresh the browser tab (Ctrl+F5) or clear site data: Persistent Failure.

    • Exit AI Studio and re-enter the project: Persistent Failure.

    • Once this state is reached, the project is dead; the only option is to delete it.

4. Expected Behavior

  • The sandbox should handle hot-reloading and VFS re-mapping for Worker scripts seamlessly.

  • Architectural changes involving threading should be reversible without corrupting the project’s persistent state or session metadata.

5. Actual Result

  • Permanent Project Corruption: The Project ID enters a terminal error state that persists regardless of user intervention.

  • Vite Path Resolution Failure: The internal Vite system cannot resolve worker.js paths during transitions, leading to 404s or invalid URL errors even when files exist in the editor.

  • VFS Lockup: The preview runner appears to be unable to clear the previous “Worker Thread” state, causing the boot sequence to hang indefinitely.

6. Technical Analysis (Hypothesis)

  1. Project-Level Metadata Deadlock: The bug likely resides in how the App Builder’s backend tracks the entry points of a project. When a worker is added/removed, the manifest desynchronizes, but the “Failed” state is cached or written to the project’s database.

  2. Service Worker / VFS Collision: The Service Worker orchestrating the sandbox environment maintains a stale reference to a non-existent worker.js blob, which interrupts the main thread’s boot process every time the project is opened.

  3. Unrecoverable Session State: Because the project “remembers” its last broken state, and there is no way to “Force Rebuild” or “Clean Cache” within AI Studio, the project remains in a boot-loop.

7. Evidence

  • UI Error Message: “Failed to load the app. Try reloading it.” (Permanent Overlay)

  • Recovery Success Rate: 0% (Tested with all standard browser and UI recovery techniques).

  • Use Case Failure: Standard frontend optimization (Multi-threading) is a “dangerous” operation that can lead to irreversible data loss.

8. Suggested Priority

URGENT/BLOCKER. This is a project-loss bug. It discourages advanced development and makes iterative architectural changes impossible. Any attempt to use Web Workers in the current App Builder environment is high-risk.

3

Hi @Kane.Yu ,

Thank you for flagging this and sharing the details. We have confirmed that Scenario A is working as expected. To help us test the remaining scenarios, could you please provide more detailed reproduction steps? Additionally, please confirm if the current result matches the expected output. It would also be very helpful if you could share a screenshot of the error message.

image
image1874×1250 296 KB

5

Thank you for your quick response. Regarding your testing, I would like to provide more specific details and two distinct project URLs to help you reproduce the core VFS/Vite deadlock issues.

1. Direct Access to Corrupted Project Instances

I have enabled sharing for two different projects that demonstrate the “Permanent Failure” states:

2. Why Scenario A may appear “Working” vs. My Failure

In my Markdown-to-PDF project, the failure in Scenario A (Main Thread to Worker) occurs when the Worker needs to load external libraries (e.g., jsPDF, markdown-it) or complex dependencies via Vite. The sandbox often fails to resolve the asset paths, throwing: Failed to construct 'Worker': The URL provided is invalid.

3. Detailed Reproduction Steps for Scenario B (The Terminal Bug)

This is the “Point of No Return” that permanently destroys the project metadata. Please follow these exact steps:

  • Step 1: Create a new App Builder project.

  • Step 2: Use this prompt: “Create a web app that uses a Web Worker (worker.js) to perform a heavy calculation (e.g., Fibonacci sequence) to keep the UI responsive. Add a button to trigger it.”

  • Step 3: Once the preview is running successfully, give a second prompt: “Actually, the calculation is not that heavy. Remove worker.js and move all the logic back into the main thread (App.jsx).”

  • Step 4: Result: The preview pane will immediately show “Failed to load the app. Try reloading it.”

  • Step 5: Try to recover by clicking “Reload”, hard-refreshing, or restarting the project. Observe that the project is now permanently dead and unresponsive.

I hope these two URLs and the specific steps help your team identify why the VFS/Vite synchronization fails permanently during architectural transitions.

Best regards