block / block/proto-fleet

Set default Connect transport timeout (all RPCs)

Open
#270 0 comments 0 reactions 0 assignees View on GitHub
client enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.