jerry/buzz

mirror of https://github.com/block/buzz.git synced 2026-10-27 12:40:30 +00:00

Files

Diem Nguyen 427488e2fc fix(desktop): surface a missing DATABRICKS_HOST instead of loading models forever (#8504 )

## Summary

If the `databricks` / `databricks_v2` provider is selected but
`DATABRICKS_HOST` isn't set, the Model field stays on "Loading
models..." forever and never shows an error.

How it happens:

1. Desktop discovers Databricks models in-process only when
`DATABRICKS_HOST` is set. Without it, discovery falls back to `buzz-acp
models`. buzz-agent then fails at config time with `DATABRICKS_MODEL
required` (model is checked first) or `DATABRICKS_HOST required`.
2. `formatModelDiscoveryErrorStatus` maps those errors, and
`BUZZ_AGENT_PROVIDER is required`, to a `null` status. The idea was that
the field's Required row would explain the problem.
3. `deriveModelDiscoveryPending` treats "no data and no status" as still
pending. So a failed discovery with a `null` status looks like it is
still loading.

The fix:

- `formatModelDiscoveryErrorStatus` now always returns a status, and its
return type is no longer nullable. A failed discovery therefore always
settles.
- A missing Databricks host shows: "Set DATABRICKS_HOST to your
Databricks workspace URL under Advanced to load Databricks models."
- A missing provider shows a muted "Choose a provider to load models."

Builds that bake `DATABRICKS_HOST` in never reach this path.

### Screenshots

Settings → Agents → Agent defaults, with Buzz Agent + Databricks v2
selected, no `DATABRICKS_HOST`, and model discovery failing with
`DATABRICKS_MODEL required`. Captured from the desktop e2e build with
the mock bridge. The only difference between the two builds is
`personaModelDiscoveryStatus.ts`.

| Before | After |
|---|---|
| ![Before: Model field stuck on Loading
models](https://raw.githubusercontent.com/block/buzz/bbdfc1f8eb91d8f0f5dc6fd98567bc6af62d8117/pr-8504--before.png)
| ![After: Model field asks for
DATABRICKS_HOST](https://raw.githubusercontent.com/block/buzz/bbdfc1f8eb91d8f0f5dc6fd98567bc6af62d8117/pr-8504--after.png)
|

### Related issue

None found. Searched open PRs that touch `personaModelDiscoveryStatus` /
`usePersonaModelDiscovery`, and issues mentioning "loading models".

### Testing

- New jsdom test drives the real `usePersonaModelDiscovery` hook with a
rejected `DATABRICKS_MODEL required` discovery. It asserts that loading
settles and that the status names `DATABRICKS_HOST`. On `main` the test
fails (`modelDiscoveryLoading` stays `true`), and it passes with this
change.
- Updated unit tests in `personaModelDiscoveryStatus.test.mjs`.
- `pnpm test` in `desktop/` passes (6834 + 161 tests). `tsc --noEmit`
and biome are clean.
- Exercised in the desktop e2e build with the mock bridge (screenshots
above). Not yet exercised in the real Tauri app.

Signed-off-by: Fizz <6be7be23ec5bba868f3e1db5ec86013d76bd1a293dce5b435a192158fec13641@buzz.block.builderlab.xyz>
Co-authored-by: Fizz <6be7be23ec5bba868f3e1db5ec86013d76bd1a293dce5b435a192158fec13641@buzz.block.builderlab.xyz>

2026-10-20 18:03:48 -07:00