Check Share Status Timing at StartupPublic

Here’s where the CLI checks share status and why it doesn’t happen “immediately” at process start.

Where the server check happens

• TraceController.reconcileSharedState() in cli/src/core/trace-controller.ts calls api.listTraces() to fetch server traces and map them to sharedUrl.
• api.listTraces() issues GET /v1/traces in cli/src/services/api.ts.

When it runs

• On TUI startup, inside the initial createEffect in cli/src/tui/app.tsx: it first loads/merges remote config, then calls controller.start(), which immediately calls reconcileSharedState().
• It runs again during controller.list() (called right after start(), and every 2s in the refresh loop), but is throttled to once per 15s (REMOTE_SHARE_REFRESH_MS = 15000) and deduped by remoteShareSyncPromise.

Why you see other work first

• loadRemoteConfig() (cli/src/services/config-loader.ts) fetches ${TRACES_URL}/config.json before controller.start().
• The initial list call (controller.list()) does adapter trace discovery and store upserts before the next share-sync attempt.

Also note

• The share sync is skipped entirely if you’re not authenticated or if any of TRACES_API_URL, TRACES_HTTP_URL, or TRACES_URL aren’t set (it clears local shared state once and returns).

If you want this to happen earlier in startup, we could move the share sync to run before loadRemoteConfig() or trigger it explicitly before controller.list().

Got it. Here’s a concise plan to make the share-status check run immediately after loadRemoteConfig() completes, before any other startup work. No changes executed yet.

Goal
Run server share-status reconciliation right after remote config is loaded, instead of waiting for controller start/list.

Plan (read-only)
Phase 1 — Core flow adjustments (lowest level first)

• Confirm the startup sequence in cli/src/tui/app.tsx around loadRemoteConfig(), controller.start(), and controller.list().
• Identify the earliest safe point to call a share-status sync (after config, before list).
• Decide whether to call controller.reconcileSharedState() directly or refactor a public “sync share status now” method on TraceController (prefer no API changes unless needed).

Phase 2 — TUI initialization ordering

• Insert the share-status sync immediately after loadRemoteConfig() and before controller.start()/controller.list().
• Ensure it respects the existing auth/config gates (so it no-ops when not logged in).

Phase 3 — Diagnostics and behavior checks

• Update diagnostics timings (if needed) to reflect the new ordering so startup metrics remain accurate.
• Verify refresh throttling (REMOTE_SHARE_REFRESH_MS) still behaves as expected with the new call order.

Atomic checklist

1. Confirm current startup order in cli/src/tui/app.tsx.
2. Decide whether to expose a public share-sync method or call existing controller method.
3. Insert share-sync call immediately after remote config load.
4. Adjust diagnostics timings if they become misleading.
5. Re-validate that unauthenticated/config-missing paths still short-circuit.

Before I proceed: do you want this to force an immediate server call even if it was recently synced (i.e., bypass the 15s throttle), or should it still respect the throttle? I recommend respecting the throttle unless you want a guaranteed call on every startup.

Understood. Here’s the concrete plan to guarantee a share-status call on every startup and only start the 15s throttle after the initial load finishes.

Plan

Phase 1 — API/Controller adjustments (lowest level first)

• Add a “force” path to TraceController.reconcileSharedState() (or a new public wrapper) so startup can bypass the 15s throttle and still set lastRemoteShareSyncAt at the end.
• Ensure the forced call still respects auth/config gating (no-op if unauthenticated or config missing), but does not skip due to timing.

Phase 2 — TUI startup ordering

• In cli/src/tui/app.tsx, right after loadRemoteConfig() resolves, call the forced share-status sync.
• Keep existing controller.start() and controller.list() sequence; the later calls will see lastRemoteShareSyncAt set, so the 15s timer begins after startup completes.

Phase 3 — Diagnostics integrity

• If diagnostics timing depends on controller start/list, verify that inserting the forced sync doesn’t skew reported metrics; adjust if needed.

Atomic checklist

1. Expose a forced share-sync option in cli/src/core/trace-controller.ts.
2. Call the forced sync immediately after loadRemoteConfig() in cli/src/tui/app.tsx.
3. Verify throttle (REMOTE_SHARE_REFRESH_MS) starts after startup finishes.
4. Confirm unauthenticated/config-missing paths still short-circuit safely.
5. Sanity-check diagnostics timing fields.

If this plan looks good, tell me to proceed and I’ll implement it.