Set default Connect transport timeout (all RPCs)
- Dominant language
- Go
- Stars
- 55
- Forks
- 16
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 87
Description
**Discovered via:** Multi-site Phase 1a code review (PR #269), but applies to every RPC in the client.
**Severity:** P2.
## Problem
Connect-RPC clients in `client/src/protoFleet/api/clients.ts` are created with the default transport — no per-call timeout, no transport-level deadline. Every read RPC inherits this.
A backend hang or partial-outage leaves any caller's `useEffect`-driven fetch sitting in a loading state for the rest of the session with no recovery path. Examples that surfaced during PR #269 review:
- `PageHeader.listSites` → SitePicker skeleton stuck.
- `SiteOverviewSection.listBuildingsBySite` → "Loading buildings…" forever.
The same risk applies to every existing read RPC (devices, racks, schedules, telemetry, etc.); the multi-site additions just made it visible.
## Recommended fix (variant (a) — transport-level deadline)
Configure `createConnectTransport` with a default per-call `timeoutMs` so every RPC has a deadline:
```ts
// client/src/protoFleet/api/transport.ts
export const transport = createConnectTransport({
baseUrl: getApiBaseUrl(),
useHttpGet: true,
// ... existing options
defaultTimeoutMs: 15_000, // 15s default; per-call override stays available
});
```
Tradeoffs:
- **Pro:** uniform behavior across every read RPC; one place to tune.
- **Pro:** composes with the AbortSignal threading shipped in PR #269 — `AbortSignal.timeout()` integration is a small follow-on.
- **Con:** project-wide change. Existing long-running calls (CSV export, large telemetry queries) may need per-call overrides. Audit needed.
## Acceptance
- Transport ships with `defaultTimeoutMs` set (number TBD via audit — `15_000` is a reasonable starting point).
- Any RPC discovered during audit that legitimately needs longer overrides via `CallOptions.timeoutMs` at the call site.
- Failed/timed-out RPCs surface a user-visible error state (consumers can build retry UI on top — the pattern landed for `SitePicker` in PR #269).
## Out of scope
- Retry/backoff strategy. Timeout alone is the smaller, safer change.
- Per-RPC override audit can land in the same PR or as a follow-up.
Contributor guide
Research direction
Start in client/src/protoFleet/api/transport.ts and inspect how createConnectTransport is configured, then review client/src/protoFleet/api/clients.ts and the read RPC call sites. Audit long-running calls such as CSV export and large telemetry queries for CallOptions.timeoutMs overrides, and check PR #269's SitePicker error-state pattern. Done means a transport default timeout is set, necessary overrides are identified, and timed-out RPCs surface user-visible errors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100