Handle null [x]ModelInfo types, recover from settings schema parse errors

[cte]

Context

If we make some bad assumptions about our settings types or bad data ever gets in the ExtensionState stores then the ContextProxy fails. This tries to avoid that.

Implementation

Screenshots

before	after

How to Test

Get in Touch

---

Important

Handle null ModelInfo types and improve error recovery in settings schema parsing, with refactoring in ContextProxy, ProviderSettingsManager, and UI components.

• Behavior:
  • ContextProxy in ContextProxy.ts now handles null ModelInfo types and recovers from settings schema parse errors by returning default values.
  • ProviderSettingsManager in ProviderSettingsManager.ts removes providerProfilesExportSchema and uses providerProfilesSchema for export.
• Types:
  • Update ProviderSettings in roo-code.d.ts and types.ts to allow null ModelInfo types.
  • Update providerSettingsSchema in schemas/index.ts to use modelInfoSchema.nullish() for model info fields.
• UI Components:
  • Extract OpenRouterBalanceDisplay and RequestyBalanceDisplay into separate components in OpenRouterBalanceDisplay.tsx and RequestyBalanceDisplay.tsx.
  • Refactor ApiOptions.tsx to use new balance display components and improve readability.

^{This description was created by for acb6d99. It will automatically update as commits are pushed.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 3b7caca

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ellipsis-dev]

The pull request includes changes across multiple files, focusing on error handling improvements and type definition updates, as well as the addition of new components for balance display. While these changes are valuable, it might be beneficial to split them into smaller, more focused pull requests.

Consider separating the changes related to error handling and type updates from the new component additions. This could help in reviewing and testing each set of changes more thoroughly.

Please evaluate if these changes can be logically divided into separate pull requests without affecting the overall functionality.