Review follow-up: byModel is ai-gateway's normalized internal form
(parseModelScopedBody treats only `default` and actual model names as
scope keys); the raw config saved to disk is `default` plus top-level
model-name keys. The help text, i18n rows and the round-trip test now
use that raw shape.
The provider dialog had no field for either, so both were config-file
only: invisible in the UI and only editable by hand-writing the config
or writing to the config database directly.
Adds two JSON boxes to the Advanced settings section, next to the usage
connector body that already uses this pattern. They open pre-filled with
whatever the provider carries, and a malformed or non-object value blocks
the save with an inline error instead of writing something the gateway
would ignore.
extraBody and extraHeaders leave providerManualFieldsForSave now that the
draft round-trips them; billing, provider and transformer stay there.
Saving a provider from the setup dialog replaced the stored entry with an
object rebuilt from the dialog draft, so every field the form does not
expose was dropped: extraBody, extraHeaders, transformer, billing and the
legacy provider protocol alias.
These only ever come from a hand-written config, and the loss is silent —
the provider keeps working, just without the upstream parameters it was
configured with. Re-typing a base URL on a provider carrying
`extraBody: { default: { reasoning_effort: "high" } }` is enough to turn
reasoning off with no error and no visible change in the UI.
Carry those fields over from the existing provider on edit. The legacy
apiKey/apikey/baseUrl/baseurl aliases are deliberately not carried over:
the form writes the canonical api_key/api_base_url, and a stale alias
would shadow the value the user just typed.
Large (>=256KB) JSON request bodies were fully JSON.parse'd and pretty-printed
in the body formatter Web Worker, which then crashed (memory/CPU) on huge object
graphs - surfacing "Body formatter worker failed." and sticking at
"Loading body...". Preview truncation only applied to non-JSON bodies.
Now, in preview mode, an over-length text body is truncated to a plain-text
preview (createLogBodyPreviewText) instead of being parsed/pretty-printed, so the
worker never chokes. Full formatting still runs in "full" mode.
The judge is the real body.text length, not sizeBytes (which may be inflated
metadata and should still render its JSON tree when lightweight).
Fixes#1694
The onboarding wizard and the Add/Edit Provider dialog render the same
AddProviderForm, but the wizard is wired up differently, and several
defects lived in those differences.
Model probe never fired during onboarding. The model-probe useEffect in
App.tsx guarded on `providerAddOpen` only, which is set true solely when
opening the manual Add/Edit Provider dialog. It is never set during the
onboarding wizard, so after entering an endpoint + API key on the Get
Started flow and reaching the "Pick models" step,
probeProviderCandidates() never fired and the model list stayed empty
with no loading state. Regressed in 9f704fc ("Guide onboarding through
granular provider setup steps"), which narrowed the guard from
`providerAddOpen || (activeView === "onboarding" && onboardingStep === "provider")`
down to `providerAddOpen`. Restore the broader guard so the probe runs
both when the dialog is open and when onboarding is on the provider step.
A rejected API key produced an empty model list with no feedback. Typing
an API key switches the probe from mode "protocols" to mode "models",
but the error-reporting branch was guarded on `probeMode !== "models"`,
so it never ran in exactly that mode. The backend still runs full
protocol probing in models mode, so a 401 came back as `supported: false`
with a real message that was then discarded. Report the failure, while
staying quiet when models were discovered, since a provider can expose a
working catalog while a protocol probe endpoint 404s.
"Added models" faked a loading state for data it already had. The panel
renders local draft state, yet showed a skeleton and hid its whole
toolbar whenever the catalog probe re-ran, leaving the header badge
reading a real count above shimmer rows and removing the "Custom model"
button, the only way to add models on a provider with no catalog. Keep
both panels' controls mounted, disabling the catalog search while
loading, which also removes a layout shift and mid-typing focus loss.
An empty catalog gave no way forward, so point at "Custom model" (en+zh).
Onboarding's "Check Connection" spent real credits with no confirmation.
The dialog wraps onCheck in a confirm step that warns about account
balance, lets the user pick models, and shows per-model results;
onboarding passed onCheckProvider straight through, so one click fired a
billable request against every configured model and discarded the
report. Extract that step as ProviderConnectivityCheckDialog and use it
from both surfaces.
ProviderConnectionStatusRow hardcoded bg-emerald-50 / border-emerald-200
/ bg-amber-50 with no dark variant, so the "Verify connection" status
chips rendered as bright light blobs on the dark card. Use alpha fills,
matching the pattern used elsewhere in the file.
The provider error banner was not announced; add role="alert".
Signed-off-by: Viet Nguyen Duc <nguyenducviet4496@gmail.com>