Provider workspace cannot add custom models #448

Activity

1. lidge-jun commented on Jul 25, 2026

   

   lidge-jun

   on Jul 25, 2026

   Owner

   More actions

   🔒 Fix in progress — assigned to the maintainer integration pass

   @lidge-jun (maintainer) is actively working this issue. Please do not open a competing PR
   for it until this marker is removed; duplicate work would have to be discarded.

   The fix is being integrated on the maintainer branch codex/260725-pr-rework (based on
   dev) together with regression coverage that pins the reported failure mode. Verification
   before merge: bun run typecheck, the full bun run test suite, bun run privacy:scan,
   bun run lint:gui, then exact-SHA hosted Cross-platform CI and Service lifecycle.

   This issue will be closed with an evidence comment naming the integration commit SHA, the
   code that closes each reported path, and the verification output. If you have additional
   reproduction detail, it is still very welcome here.

   _{Integration tracker: devlog/_plan/260725_pr_issue_rework · marker posted by the maintainer integration pass}
2. lidge-jun

   added a commit that references this issue on Jul 25, 2026

   feat(gui): add custom models from provider workspace (#448)

   ...

   121a351
3. lidge-jun commented on Jul 25, 2026

   

   lidge-jun

   on Jul 25, 2026

   Owner

   More actions

   Fixed in dev

   Commit: 121a3512 (PR #449 by @apple-ouyang, plus two follow-on repairs) · merged into dev at ebc62d1f

   Both halves of the report are addressed.

   Provider-scoped custom model input. The Models tab now has an add field scoped to the current provider. Empty ids, namespaced ids containing /, and duplicates (against discovered, custom, configured, and default models) are rejected client-side, and the server re-validates and returns 409 on a duplicate race. A successful add appears immediately.

   Custom rows no longer suppress configured fallbacks. The original code inferred "does this provider have a live catalog?" by subtracting known custom ids from the catalog. That breaks precisely when a custom id later also appears in live discovery: the subtraction leaves nothing, the live catalog is misread as custom-only, and the configured fallback wrongly stays authoritative. Provenance is now recorded at the source — a successful discovery records how many rows it actually returned (captured before configured-alias augmentation), /api/selected-models carries it, and the GUI reads that instead of guessing. The count argument and the GUI prop are both required, so a missed wiring is a compile error rather than a silent zero.

   A second defect was repaired in the same commit: a single failed /api/custom-models GET left the panel permanently unable to add a model, because customModelsReady never flipped back and the effect had no remaining trigger. There is now a Retry control with an epoch-based refetch.

   Verification

   • Discovery provenance is exercised through the real path (non-empty, successful-empty, and failure-preserves-last-count); removing the count recording fails two of the three
   • The recovery regression drives GET fail → Retry → success → Add enabled → POST exactly once in a single mount
   • GUI suite: 148 pass / 0 fail; build clean. Full suite at merge: 4222 pass / 0 fail
   • Rendered check at 1280×720: with a custom id that also appears in live discovery, the configured fallback correctly stays hidden; console clean
   • Cross-platform CI on ebc62d1f: green on ubuntu, macOS, Windows

   Thanks for the clear separation of the two symptoms in the report — the fallback-suppression half was the subtler one.
4. lidge-jun

   closed this as completedon Jul 25, 2026
5. agentHits

   added a commit that references this issue on Sep 17, 2026

   feat(gui): add custom models from provider workspace (lidge-jun#448)

   ...

   59091a2