⚡ Bolt: concurrent dev server and zimaos gateway status fetching

[bobdivx]

💡 What: Refactored the dashboard-projects-health API route to fetch project dev server states concurrently using an array of mapped Promises, rather than sequentially blocking on 'isPortListening' file IO and network calls. It also launches the remote ZimaOS session payload lookup concurrently early in the API execution.
🎯 Why: Iterating over multiple projects using a synchronous 'for...of' loop containing network tests aggregates their potential timeout periods linearly. Parallelizing them reduces the total wait time to the slowest single operation.
📊 Impact: Considerably faster initial response times on dashboards with multiple active and inactive projects.
🔬 Measurement: Verify dashboard card loading times and run tests via 'pnpm test'.

---

PR created automatically by Jules for task 17039892674323419020 started by @bobdivx

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
forge	Ready	Preview, Comment	Jun 17, 2026 5:26pm

[gemini-code-assist]

Code Review

This pull request optimizes the dashboard projects health API route by parallelizing I/O operations, initiating the Zima session fetch early, and running project status checks concurrently. Feedback focuses on improving the promise handling: chaining the .catch directly to return a fallback object, using Promise.all instead of sequentially awaiting promises in a loop, caching database queries to avoid redundant roundtrips during concurrent checks, and correcting a misconception in the documentation regarding Promise.all preserving order.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Instead of using a floating .catch(() => {}) on the promise and discarding its result, it is safer and cleaner to chain the .catch directly to the promise assignment. This ensures that fetchZimaPromise is guaranteed to resolve to a valid ZimaOSSessionsPayloadResult object, preventing any potential unhandled rejections or runtime errors when it is awaited later.

  // Optimisation Bolt : on lance le fetch gateway tout de suite (sans await bloquant).
  const fetchZimaPromise = fetchZimaOSSessionsPayload(email).catch((err) => ({
    ok: false,
    data: [],
    status: 500,
    error: err instanceof Error ? err.message : String(err),
    attempts: [],
  }));

[gemini-code-assist]

Mapping over the projects to call resolveProjectPathFromDbProject concurrently will trigger concurrent database queries for the same configuration (forgeReposRoot) for each project. While parallelizing the dev server status checks is great, consider caching or pre-fetching the repository root configuration to avoid redundant database roundtrips.

[gemini-code-assist]

Using Promise.all is more idiomatic and cleaner than sequentially awaiting each promise in a for...of loop. Note that Promise.all preserves the original order of the array perfectly.

    const resolvedProjects = await Promise.all(devPromises);
    payload.projects.push(...resolvedProjects);

[gemini-code-assist]

Note that Promise.all actually preserves the order of the resolved values in the returned array, matching the order of the input promises. Therefore, Promise.all is perfectly suitable even when order matters.

Suggested change

	**Action:** When iterating over independent operations that involve file I/O or network calls, map them to an array of async Promises to initiate them concurrently. Then sequentially `await` the promises array to resolve them while maintaining order, or use `Promise.all` if order matters less, reducing the overall time bound to the single longest operation.
	**Action:** When iterating over independent operations that involve file I/O or network calls, map them to an array of async Promises to initiate them concurrently. Then use Promise.all to resolve them concurrently, which also preserves the original order of the array, reducing the overall time bound to the single longest operation.