17 lines
1.4 KiB
Markdown
17 lines
1.4 KiB
Markdown
# Frontend operation registry
|
|
|
|
Harbor tracks active browser mutations by operation key instead of one global `busy` flag:
|
|
|
|
- `connection`: start, stop and restart;
|
|
- `serverApply`: apply a `(profileId, serverId)` pair;
|
|
- `profileAdd`, `profileRename`, `profileSelect`, `profileActivate`, `profileRefresh`, `profileDelete`;
|
|
- `gatewayAuto`: change the active route preference.
|
|
|
|
Each entry is `{ status: "running", startedAt }`. A repeated operation key receives the same in-flight Promise, so a double click sends one request. A conflicting key resolves to `false` without starting its action. The symmetric conflict matrix lives in `src/web/state/operations.ts`.
|
|
|
|
The registry only disables controls that can mutate the same domain state. Copy actions, instruction navigation and local tabs remain available during subscription refresh. Progress is announced with `role="status"`; the structured error from TASK-004 remains `role="alert"` after failure.
|
|
|
|
Subscription URL validation is local and accepts only well-formed `http` and `https` URLs. It does not contact the provider; explicit profile add performs the single provider request and reports provider failures at that profile.
|
|
|
|
The registry is local transport/UI state for immediate feedback. It does not replace backend `snapshot.operation`, which preserves the target across polling, reloads and other windows. A `diagnostics` key is intentionally deferred until diagnostics become a conflicting mutation.
|