#19020: bugfix(gateway): Handle invalid model provider API config gracefully\…

This PR addresses #18968 by implementing fault-tolerant configuration loading for model providers. Previously, an invalid `models.providers.<provider>.api` field would cause the entire Gateway to crashloop. Now, `validateConfigObjectRaw` uses Zod's `safeParse` to: - Identify specific validation issues within `models.providers`. - Exclude invalid providers from the returned configuration. - Log a warning for disabled providers. - Allow the Gateway to start successfully with all other valid configurations. A new test case has been added to `config.schema-regressions.test.ts` to verify this graceful degradation. Fixes #18968 ## Summary - **Problem:** Invalid `models.providers.<provider>.api` field in `openclaw.json` caused Gateway to crashloop. - **Why it matters:** Critical system instability and poor Developer Experience (DX). - **What changed:** Configuration validation now gracefully disables individual problematic model providers without crashing the Gateway. - **What did NOT change:** Core validation logic from Zod; behavior for entirely unparseable `openclaw.json` (still exits for critical errors). ## Change Type - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope - [x] Gateway / orchestration - [ ] Skills / tool execution - [x] Auth / tokens (indirectly, as `apiKey` is part of provider config) - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [x] UI / DX (improved robustness during config issues) - [ ] CI/CD / infra ## Linked Issue/PR - Closes #18968 ## User-visible / Behavior Changes - An invalid `models.providers.<provider>.api` (or other provider-specific configuration error) will no longer crash the OpenClaw Gateway. - The Gateway will start, but the problematic provider will be disabled. - A warning will be logged to the console/system logs (`console.warn`) indicating which provider failed and why. - `openclaw status` will show the problematic provider as disabled. ## Security Impact - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`No`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) ## Repro + Verification ### Environment - OS: `Linux 6.17.0-14-generic (x64)` - Runtime/container: `Node.js v22.22.0` - Model/provider: Any configured LLM provider (e.g., Google, Anthropic, OpenAI) - Integration/channel (if any): N/A - Relevant config (redacted): ```json { "models": { "providers": { "google": { "baseUrl": "https://generativelanguage.googleapis.com/v1beta", "apiKey": "AIzaSy-REDACTED-KEY", // Redacted "api": "invalid-google-api-type", // The invalid field "models": [ { "id": "gemini-2.5-flash", "name": "Gemini 2.5 Flash" } ] }, "anthropic": { "baseUrl": "https://api.anthropic.com/v1", "apiKey": "sk-ant-REDACTED-KEY", // Redacted "api": "anthropic-messages", "models": [ { "id": "claude-3-opus-20240229", "name": "Claude 3 Opus" } ] } } } } <!-- greptile_comment --> <h3>Greptile Summary</h3> Implements graceful degradation for invalid model provider configurations by using Zod's `safeParse` to identify validation errors, filter out problematic providers, and allow the Gateway to start with remaining valid providers instead of crashing. **Key changes:** - Modified `validateConfigObjectRaw` to collect all validation issues and filter out invalid providers rather than failing fast - Invalid providers in `models.providers` are now excluded from the returned config with console warnings - Returns config even when validation fails (graceful degradation) - Added comprehensive test coverage for the new behavior **Issues found:** - **Critical type mismatch**: Return type signatures don't reflect that `config` is now included in error responses (lines 93, 184) <h3>Confidence Score: 3/5</h3> - This PR introduces a useful feature but has a type safety issue that must be fixed before merging - The implementation logic for graceful degradation is sound and well-tested, but the TypeScript return type signatures are incorrect, which will cause type errors when the code is compiled or used by callers expecting proper types - src/config/validation.ts requires type signature fixes on lines 93 and 184 _{Last reviewed commit: 9d7c8f6} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->