## Summary The Configuration page shows an infinite loading spinner due to an uncaught `TypeError: can't convert undefined to object` in `formatConfig()`. ## Root cause `formatDatabases()` and `formatDumpCustomOptions()` in `ui/packages/shared/pages/Instance/Configuration/utils/index.ts` guard against `null` with strict equality (`!== null`), but receive `undefined` when fields are absent from the API response. The call sites in `ui/packages/shared/types/api/entities/config.ts` use incorrect type assertions (`as DatabaseType | null`) that mask `undefined` values from optional chaining: ```typescript databases: formatDatabases( config.retrieval?.spec?.logicalDump?.options ?.databases as DatabaseType | null, // actually undefined, not null ), ``` When `undefined !== null` evaluates to `true`, the code proceeds to `Object.keys(undefined)` which throws. ## When it triggers Whenever the `/admin/config` response omits `databases` or `customOptions` fields. This happens in practice: 1. **Fresh instance with no retrieval configured** — the entire `retrieval` section is absent 2. **Standard config template** (`config.example.logical_generic.yml`) — `databases` is a commented-out example, so the projection omits it even though `retrieval.spec` exists This means the bug affects virtually every fresh DBLab deployment using the CE UI. ## Browser console error ``` Uncaught (in promise) TypeError: can't convert undefined to object formatDatabases (utils/index.ts) formatConfig (config.ts) getConfig (Main.ts) ``` ## Fix Replace incorrect `as Type | null` assertions with `?? null` (nullish coalescing) so that `undefined` values from optional chaining are converted to `null` before reaching the guard: ```typescript databases: formatDatabases( (config.retrieval?.spec?.logicalDump?.options ?.databases as DatabaseType | undefined) ?? null, ), ``` Same pattern for `pgDumpCustomOptions` and `pgRestoreCustomOptions`.