Astro dev intermittently crashes when `astro:actions` is used in a server island

[TorbjornHoltmon]

Astro Info

Astro                    v7.3.4
Node                     v24.19.0
System                   macOS (arm64)
Package Manager          pnpm
Output                   server
Adapter                  @astrojs/cloudflare
Integrations             none

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

When using astro:actions inside a server island with @astrojs/cloudflare, the Astro dev server eventually starts returning 500 errors.

Even though the patch in the repro prevents the issue, we do not know if the fix has any negative consequences. We are not that familiar with the astro and vite architecture.

Credit goes to my colleague @rognstadragnar for reproducing this issue.

What's the expected result?

The server island should continue rendering successfully regardless of how many times the page is requested.

Link to Minimal Reproducible Example

https://github.com/TorbjornHoltmon/astro-actions-server-islands-repro

Participation

• I am willing to submit a pull request for this issue.

[astro-factory]

Triage stopped

• Prepare the workspace: ready
• Install dependencies: complete
• Build the project: complete
• Reproduce the issue failed
• Diagnose the cause
• Verify the diagnosis
• Attempt a fix
• Publish the result

---

Triage failed unexpectedly (attempt 1 of 3).

I can retry if a new comment provides more information or asks me to try again.

Error:

Error: Pipeline stage "reproduce" failed (submission sub_ik_d0259c324111f72d254f3a9bc76b01c2).
AgentRunError: [flue] Agent run failed (submission sub_ik_d0259c324111f72d254f3a9bc76b01c2).
Caused by: FlueError: Submission exceeded the configured timeout.

[TorbjornHoltmon]

Bot, please try again. If you write a bash script to spam the root you will eventually see the error. Remember that this is not built, this is when running the dev server.

[astro-factory]

Triage complete

• Prepare the workspace: ready
• Install dependencies: complete
• Build the project: complete
• Reproduce the issue: not reproduced
• Diagnose the cause: not needed (the issue was not reproduced)
• Verify the diagnosis: not needed (the issue was not reproduced)
• Attempt a fix: not needed (the issue was not reproduced)
• Publish the result: set triage: unable to reproduce

---

• Reproduced: No — the issue is an intermittent race condition that could not be triggered in our Linux + Node 22 sandbox despite extensive concurrent request testing (2000+ requests with file-change-forced re-transforms). The bug likely depends on timing characteristics specific to macOS arm64 + Node 24.
• Exploration: Partial — View branch
• Unit Test: No — reproduction failed, so no failing test was produced
• Priority: P3: minor bug. This is an intermittent dev-server-only issue specific to the @astrojs/cloudflare adapter (or other adapters using non-runnable environments with large pre-bundled module graphs). It does not affect production builds.

Code analysis strongly supports this being a real bug. In two places — vite-plugin-server-islands.ts (line 134) and vite-plugin-head/index.ts (line 51) — Astro calls env.moduleGraph.invalidateModule(mod) on virtual modules during the transform hook. Vite's invalidateModule recursively cascades to all importers, which in the Cloudflare adapter's pre-bundled SSR environment means invalidating astro:actions, the full Astro runtime, and nearly every component. Concurrent requests during the resulting re-evaluation window can observe partially-initialized module exports (e.g., actions being undefined), causing the 500 errors.

I wasn't able to find a fix, but I identified some areas that may be relevant. The user's patch in the reproduction repo replaces invalidateModule(mod) with a targeted mod.transformResult = null (plus etag cleanup) at both locations. This avoids the cascade while still ensuring the next dynamic import() of the virtual module gets a fresh version. The relevant files are:

• packages/astro/src/core/server-islands/vite-plugin-server-islands.ts — line 134
• packages/astro/src/vite-plugin-head/index.ts — line 51 (the invalidateComponentMetadataModule function)

Full Triage Report

Original Issue

Title: Astro dev intermittently crashes when astro:actions is used in a server island
Author: @TorbjornHoltmon (CONTRIBUTOR)
Reproduction: https://github.com/TorbjornHoltmon/astro-actions-server-islands-repro

Environment

• Astro v7.3.4
• Node v24.19.0
• macOS (arm64)
• Package Manager: pnpm
• Output: server
• Adapter: @astrojs/cloudflare
• Integrations: none

Description

When using astro:actions inside a server island with @astrojs/cloudflare, the Astro dev server eventually starts returning 500 errors after repeated page requests. The issue is intermittent — it may happen after ~20 requests or sometimes 50-100+. The vite dependency cache must be cleared (rm -rf node_modules/.vite) before starting for the error to reproduce.

Reproduction Setup

The repro project has:

• astro.config.mjs: Uses @astrojs/cloudflare adapter with output: 'server'
• src/pages/index.astro: Contains <IslandA server:defer />
• src/components/IslandA.astro: A server island that imports astro:actions and calls Astro.callAction(actions.a.get, {})
• src/lib/hooks.ts: Imports actions from astro:actions at module top level and exports a reference
• src/actions/index.ts: Defines a simple action a.get

User-Provided Patch

The repro includes a patch that modifies two locations:

1. vite-plugin-server-islands.js: Replaces env.moduleGraph.invalidateModule(mod) with targeted mod.transformResult = null
2. vite-plugin-head/index.js: Same change for the component metadata virtual module

---

Reproduction Attempt

Sandbox Environment

• Astro v7.3.5 (current main branch)
• Node v22.23.2
• Linux x64
• workerd was available and running (confirmed via ps aux)

Steps Taken

1. Created reproduction project using the monorepo workspace with @astrojs/cloudflare adapter
2. Installed dependencies and confirmed workspace package linking
3. Cleared vite cache (rm -rf node_modules/.vite) before each attempt
4. Sent concurrent requests using multiple approaches:
   • Sequential requests (200 requests): No failures
   • Concurrent curl batches (10 concurrent × 30 batches = 300 requests): No failures
   • Node.js concurrent HTTP client (20 concurrent × 100 batches = 2000 requests): No failures
   • File modifications during concurrent requests (forcing re-transforms): No failures
5. Verified pre-bundling occurred — node_modules/.vite/deps_ssr/ contained pre-bundled astro modules
6. Checked debug logs — hooks.ts was re-evaluated 131 times (due to forced file changes), but typeof actions was always object (never undefined)

Result

Could NOT reproduce the 500 error despite extensive testing.

---

Code Analysis

The Problem: invalidateModule Cascade

Vite 8's EnvironmentModuleGraph.invalidateModule():

1. Clears transformResult, ssrModule, and ssrError on the target module
2. Recursively invalidates ALL importers (not HMR-accepted)

Two locations in Astro call this on virtual modules during transform:

Location 1 — packages/astro/src/core/server-islands/vite-plugin-server-islands.ts (line 134):

if (serverIslandsState.hasIslands()) {
    for (const env of serverEnvironments) {
        const mod = env.moduleGraph.getModuleById(RESOLVED_SERVER_ISLAND_MANIFEST);
        if (mod) {
            env.moduleGraph.invalidateModule(mod); // cascades to ALL importers
        }
    }
}

Location 2 — packages/astro/src/vite-plugin-head/index.ts (line 51):

function invalidateComponentMetadataModule() {
    for (const env of environments) {
        const virtualMod = env.moduleGraph.getModuleById(RESOLVED_VIRTUAL_COMPONENT_METADATA);
        if (virtualMod) {
            env.moduleGraph.invalidateModule(virtualMod); // cascades to ALL importers
        }
    }
}

Why Cloudflare Is Affected

The @astrojs/cloudflare adapter pre-bundles ~30+ astro modules in the ssr environment via optimizeDeps.include. These form an interconnected graph. The invalidateModule cascade reaches the pre-bundled astro runtime, astro:actions, and nearly every component. Concurrent requests during the re-evaluation window can observe partially-initialized module exports.

Proposed Fix (from User's Patch)

Replace invalidateModule(mod) with:

if (mod?.transformResult) {
    env.moduleGraph.etagToModuleMap?.delete(mod.transformResult.etag);
    mod.transformResult = null;
}

This is sufficient because both virtual modules are consumed via dynamic import() — dropping transformResult ensures the next import gets a fresh version without cascading to the entire pre-bundled tree.

Related Work

PR #18007 (in v7.3.4) fixed the head-metadata plugin's self-invalidation loop but did NOT change the fundamental invalidateModule cascade behavior.

This report was made by an LLM. The analysis may be wrong, and the potential fix might not work, but is intended as a starting point for exploring the issue.