fix:perf: slow startup due to blocking provider probes at startup

[IdrisGit]

What Changed

Make the initial provider refresh purely background. Boot-time providersRef is now seeded from:

1. On-disk per-instance cache.
2. Pending fallbacks (new "pending" status) for configured instances missing a cache hit.
3. Eager unavailable instances.

The background syncLiveSources is now forked, so regardless of probe latency the backend server is ready asap and renderer can start the window paint.

Why

Backend HTTP readiness was coupled to provider probing. If a provider took time to time to respond or maybe in future have many providers, until each provider is resolved, the backend server doesn't start causing renderer to not start painting, leading to slow startup time.

By decoupling the provider probing (with cache check initially) we eliminate the synchronous dependency and app starts pretty quickly.

Benchmarks

I benchmarked the wall clock time for start to window open and as you can see there is a good degree of improvement, and this doesn't encapsulate if any provider itself is buggy which can cause even longer startup time.

Ideally the startup time should be atleast sub 1 second, but I think this is step in that direction.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

few of the line changes are not actually code changes,
but formatting fixes that were auto applied with bun run fmt

fixes #2726 and maybe #2442

---

Note

Medium Risk
Changes provider registry startup sequencing and snapshot hydration, which can affect initial UI/provider state and cache behavior. Also expands the ServerProviderState contract with a new pending value that downstream consumers must handle.

Overview
Decouples backend readiness from provider probing by forking the initial syncLiveSources refresh to run fully in the background, instead of awaiting provider refreshes during layer startup.

Boot-time provider state is now hydrated from on-disk cache with a bounded (100ms) best-effort snapshot fallback; instances without cache/fallback are surfaced immediately as a new pending provider snapshot. Unavailable instances are also upserted eagerly at boot so the UI can render missing-driver/ghost providers before background refresh completes.

Updates the contracts schema to include "pending" in ServerProviderState.

^{Reviewed by Cursor Bugbot for commit f4d3212. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix slow startup caused by blocking provider probes in ProviderRegistryLive

• The initial provider sync now runs in the background via a forked fiber instead of blocking layer construction, so the app starts up without waiting for provider probes.
• Boot-time snapshot loading is bounded to 100ms; if the fallback load times out, the registry continues with no fallback providers rather than waiting indefinitely.
• Providers with no cached or fallback data are now represented as 'pending' snapshots so they appear immediately in the registry instead of being omitted.
• Unavailable instances from instanceRegistry.listUnavailable are eagerly added to providersRef without waiting for a refresh.
• Adds 'pending' as a valid literal to the ServerProviderState schema in server.ts.
• Behavioral Change: providersRef is now populated with pending/cached entries at boot rather than only confirmed-available providers, so consumers may briefly see providers in a 'pending' state.

^{Macroscope summarized f4d3212.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 72cdbbf2-2513-4762-b2c9-fceac999a794

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR changes startup behavior significantly - providers now load asynchronously with a new 'pending' state instead of blocking until ready. This is a runtime behavior change affecting what users observe during startup, not a simple bug fix.

^{You can customize Macroscope's approvability policy. Learn more.}