Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix doctor --fix crashes with Config validation failed on models.providers.google.baseUrl [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#53756•Fetched 2026-04-08 01:23:50
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
mahopanmahopan
Participants
mahopanmahopan
Timeline (top)
cross-referenced ×2closed ×1locked ×1

Error Message

Error: Config validation failed: models.providers.google.baseUrl: Invalid input: expected string, received undefined

Root Cause

In src/commands/doctor-legacy-config.ts, the nano-banana migration creates a partial models.providers.google = { apiKey: "..." } object when no pre-existing google provider config exists. The ModelProviderSchema requires baseUrl and models but the migration only sets apiKey.

Fix Action

Workaround

Manually set the required fields before running doctor:

openclaw config set models.providers.google.baseUrl "https://generativelanguage.googleapis.com"
openclaw config set models.providers.google.models "[]"
openclaw doctor --fix

PR fix notes

PR #53757: fix(doctor): add missing baseUrl and models when migrating nano-banana apiKey to google provider

Description (problem / solution / changelog)

Summary

Fixes #53756

The legacy nano-banana-pro skill migration moves the Gemini API key to models.providers.google.apiKey but does not populate the required baseUrl and models fields on the provider entry. When the google provider object is freshly created (no pre-existing config), the resulting config fails Zod validation on write:

Error: Config validation failed: models.providers.google.baseUrl: Invalid input: expected string, received undefined

Fix

When migrating the API key to a new google provider entry, default baseUrl to "https://generativelanguage.googleapis.com" and models to [] if not already set. This matches the defaults used elsewhere in the codebase (embeddings-gemini.ts, pdf-native-providers.ts).

Changes

  • src/commands/doctor-legacy-config.ts: Add baseUrl and models defaults when creating the google provider entry during nano-banana migration
  • src/commands/doctor-legacy-config.migrations.test.ts: Verify baseUrl and models are set in migration test cases

Changed files

  • src/commands/doctor-legacy-config.migrations.test.ts (modified, +8/-0)
  • src/commands/doctor-legacy-config.ts (modified, +6/-0)

PR #53841: fix(doctor): preserve valid google provider shape in nano-banana migration

Description (problem / solution / changelog)

Summary

  • Problem: openclaw doctor --fix could migrate legacy skills.entries.nano-banana-pro config into an invalid models.providers.google object.
  • Why it matters: the migration wrote apiKey only, then config validation failed because ModelProviderSchema requires baseUrl and models.
  • What changed: the nano-banana migration now fills missing google.baseUrl and google.models when it introduces the google provider entry.
  • What did NOT change (scope boundary): no broader provider normalization/refactor; existing explicit native google config is preserved.
  • AI-assisted: yes (prepared with Codex/OpenClaw assistance).
  • Testing level: lightly tested but targeted to the affected migration path.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #53756
  • Related #53756
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: normalizeCompatibilityConfigValues() migrated legacy nano-banana config into models.providers.google.apiKey but did not materialize the rest of the required ModelProviderSchema shape.
  • Missing detection / guardrail: there was no regression test asserting that the migrated google provider entry is schema-valid when created from legacy nano-banana config alone.
  • Prior context (git blame, prior PR, issue, or refactor if known): reported in #53756 with a direct repro against doctor --fix.
  • Why this regressed now: legacy migration handled the model selection + API key move, but not the required provider defaults for a newly created google provider entry.
  • If unknown, what was ruled out: N/A.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/commands/doctor-legacy-config.migrations.test.ts
  • Scenario the test should lock in: migrating legacy skills.entries.nano-banana-pro config with no pre-existing models.providers.google should produce a schema-valid google provider entry including baseUrl and models.
  • Why this is the smallest reliable guardrail: the bug is introduced entirely inside the legacy migration logic, so the migration test is the narrowest place to prevent recurrence.
  • Existing test that already covers this (if any): the nano-banana migration test existed, but it did not assert the full required google provider shape.
  • If no new test is added, why not: N/A.

User-visible / Behavior Changes

  • openclaw doctor --fix no longer fails validation when migrating legacy skills.entries.nano-banana-pro config into models.providers.google.

Diagram (if applicable)

N/A

Security Impact (required)

  • New permissions/capabilities? (Yes/No): No
  • Secrets/tokens handling changed? (Yes/No): No
  • New/changed network calls? (Yes/No): No
  • Command/tool execution surface changed? (Yes/No): No
  • Data access scope changed? (Yes/No): No
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • OS: macOS 25.3.0 (arm64)
  • Runtime/container: local repo checkout, Node 25.5.0, pnpm 10.32.1
  • Model/provider: N/A
  • Integration/channel (if any): N/A
  • Relevant config (redacted): legacy skills.entries.nano-banana-pro with apiKey or env.GEMINI_API_KEY, and no pre-existing models.providers.google

Steps

  1. Configure legacy skills.entries.nano-banana-pro with an API key.
  2. Ensure models.providers.google is absent.
  3. Run openclaw doctor --fix.

Expected

  • Legacy config migrates successfully.
  • Resulting models.providers.google is schema-valid.

Actual

  • Before this patch, validation failed with models.providers.google.baseUrl: Invalid input: expected string, received undefined.
  • After this patch, the migration test passes and asserts the required google provider shape.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Verified scenarios:
    • ran pnpm exec vitest run src/commands/doctor-legacy-config.migrations.test.ts
    • verified migrated config now includes models.providers.google.baseUrl and models.providers.google.models
    • commit-time local checks passed during commit creation
  • Edge cases checked:
    • preserves explicit existing native google provider config
    • prefers legacy env.GEMINI_API_KEY over legacy skill apiKey during migration
  • What you did not verify:
    • did not run full pnpm build && pnpm check && pnpm test
    • did not run broader end-to-end doctor flows
    • did not run codex review --base origin/main yet

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No): Yes
  • Config/env changes? (Yes/No): No
  • Migration needed? (Yes/No): No
  • If yes, exact upgrade steps: N/A

Risks and Mitigations

  • Risk: migration could accidentally overwrite explicit google provider config.
    • Mitigation: changes only fill missing defaults in the path where the migration introduces the provider config; existing explicit config remains covered by regression tests.

Changed files

  • src/commands/doctor-legacy-config.migrations.test.ts (modified, +2/-2)
  • src/commands/doctor/shared/legacy-config-core-normalizers.ts (modified, +10/-6)
  • src/media/store.ts (modified, +12/-4)

Code Example

Error: Config validation failed: models.providers.google.baseUrl: Invalid input: expected string, received undefined

---

openclaw config set models.providers.google.baseUrl "https://generativelanguage.googleapis.com"
openclaw config set models.providers.google.models "[]"
openclaw doctor --fix
RAW_BUFFERClick to expand / collapse

Bug

Running openclaw doctor --fix fails with:

Error: Config validation failed: models.providers.google.baseUrl: Invalid input: expected string, received undefined

Reproduction

  1. Have a legacy skills.entries.nano-banana-pro config with an apiKey (but no existing models.providers.google section)
  2. Run openclaw doctor --fix
  3. The migration moves the API key to models.providers.google.apiKey but does not populate the required baseUrl or models fields
  4. Config write fails Zod validation (ModelProviderSchema requires baseUrl: z.string().min(1) and models: z.array(...))

Root Cause

In src/commands/doctor-legacy-config.ts, the nano-banana migration creates a partial models.providers.google = { apiKey: "..." } object when no pre-existing google provider config exists. The ModelProviderSchema requires baseUrl and models but the migration only sets apiKey.

Expected

doctor --fix should successfully migrate the legacy nano-banana config without crashing.

Workaround

Manually set the required fields before running doctor:

openclaw config set models.providers.google.baseUrl "https://generativelanguage.googleapis.com"
openclaw config set models.providers.google.models "[]"
openclaw doctor --fix

extent analysis

Fix Plan

To fix the issue, we need to update the doctor-legacy-config.ts file to populate the required baseUrl and models fields when migrating the legacy nano-banana config.

Steps:

  • Update the nano-banana migration in src/commands/doctor-legacy-config.ts to include the required fields:
// ...
if (!config.models.providers.google) {
  config.models.providers.google = {
    apiKey: legacyConfig.apiKey,
    baseUrl: 'https://generativelanguage.googleapis.com', // add default baseUrl
    models: [], // add default models array
  };
}
// ...
  • Alternatively, you can use the workaround provided in the issue body to manually set the required fields before running doctor --fix.

Verification

To verify that the fix worked, run openclaw doctor --fix again and check that the config migration is successful without any errors.

Extra Tips

  • Make sure to test the updated doctor-legacy-config.ts file with different legacy config scenarios to ensure that the fix does not introduce any regressions.
  • Consider adding additional validation or error handling to the doctor-legacy-config.ts file to handle any potential edge cases or invalid config inputs.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#chain error#conversation history#tool integration#LLM response

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING