⚡ perf: parallelize sequential network requests in Hotel Store

[chuanman2707]

💡 What:
Parallelized fetchRooms(), fetchStats(), fetchGroups(), and fetchHousekeeping() calls within useHotelStore.ts (e.g. checkIn, groupCheckin, checkOut, extendStay, updateHousekeeping) using Promise.all(). Also added a baseline test mhm/tests/e2e/15-store-performance.test.ts to capture mock execution durations.

🎯 Why:
Previously, these fetch actions were awaited sequentially after their respective API actions. This sequential execution caused a waterfall delay since each data request waited for the previous one to complete, resulting in slower perceived action times. Fetch operations can safely run simultaneously.

📊 Measured Improvement:
In a local benchmark using mocked slow endpoints (delay(100) for fetch queries, delay(50) for check-in action):

• checkIn execution time: Improved from ~253ms sequentially to ~158ms in parallel (a nearly 100ms improvement).
• groupCheckin execution time: Improved from ~353ms sequentially to ~158ms in parallel (a nearly 200ms improvement).

---

PR created automatically by Jules for task 11173198085945660925 started by @chuanman2707

[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.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5df9d1ba9c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Await parallel refreshes before clearing loading state

Using Promise.all here causes an early reject when any refresh fails, so the catch/finally path runs and endAction() clears loading while other refresh calls are still in flight. In scenarios like get_rooms failing quickly but get_dashboard_stats completing later, the action reports failure and stops loading prematurely, then late responses can still mutate store state after the action has ended; this regression now affects all similarly parallelized booking actions (checkIn, checkOut, extendStay, groupCheckIn, groupCheckout).

Useful? React with 👍 / 👎.

[chuanman2707]

Holding this PR. The Promise.all() change improves happy-path latency, but it also changes failure behavior for the refresh calls, and the benchmark test only logs timings without protecting correctness. Please recut this with behavior-safe refresh handling and targeted assertions if we want to merge it.

[google-labs-jules]

Holding this PR. The Promise.all() change improves happy-path latency, but it also changes failure behavior for the refresh calls, and the benchmark test only logs timings without protecting correctness. Please recut this with behavior-safe refresh handling and targeted assertions if we want to merge it.

Good catch! Switching from sequential await to Promise.all did indeed change the failure behavior. I've updated the store actions to use a new safeRefresh helper based on Promise.allSettled, which executes the refresh queries concurrently but safely swallows errors without failing the primary operation. I also added a targeted assertion in the benchmark test file to prove that a failed refresh doesn't prevent other refreshes or crash the main action.