openclaw - ✅(Solved) Fix Config schema rejects legacy messages.tts.edge while docs/types still say it is supported [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#56220Fetched 2026-04-08 01:43:25
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
Participants
Timeline (top)
cross-referenced ×3referenced ×2

Current config validation rejects messages.tts.edge as an unrecognized key, but the repo still documents it as a supported legacy alias and the TypeScript config type still includes it.

Root Cause

Current config validation rejects messages.tts.edge as an unrecognized key, but the repo still documents it as a supported legacy alias and the TypeScript config type still includes it.

Fix Action

Fixed

PR fix notes

PR #56241: fix: Config schema rejects legacy messages.tts.edge while docs/types still say it is supported

Description (problem / solution / changelog)

Issue

Closes #56220

Config validation rejects messages.tts.edge as an unrecognized key, but documentation and TypeScript types still declare it as supported.

Changes

Added explicit tests to verify that TtsConfigSchema accepts the legacy messages.tts.edge configuration key. This ensures:

  1. The edge field is properly validated in the TTS config schema
  2. All edge TTS configuration options are supported (voice, lang, outputFormat, pitch, rate, volume, saveSubtitles, proxy, timeoutMs)
  3. Existing configurations using edge TTS settings continue to work

Tests

  • Added test for edge field with basic voice configuration
  • Added test for edge field with all configuration options

All tests pass.

Checklist

  • Tests added
  • Tests pass
  • Minimal change focused on the issue

Changed files

  • src/config/zod-schema.tts.test.ts (modified, +35/-0)

PR #56280: fix: accept legacy messages.tts.edge config

Description (problem / solution / changelog)

Summary

  • accept legacy messages.tts.edge and messages.tts.microsoft shapes in TtsConfigSchema
  • preserve existing migration path into messages.tts.providers.microsoft
  • add regression coverage for legacy config validation

Fixes #56220

Changed files

  • src/config/zod-schema.core.ts (modified, +41/-0)
  • src/config/zod-schema.tts.test.ts (modified, +12/-12)

Code Example

{
  messages: {
    tts: {
      auto: "always",
      provider: "edge",
      edge: {
        voice: "en-US-AvaMultilingualNeural"
      }
    }
  }
}
RAW_BUFFERClick to expand / collapse

Summary

Current config validation rejects messages.tts.edge as an unrecognized key, but the repo still documents it as a supported legacy alias and the TypeScript config type still includes it.

Repro

Config snippet:

{
  messages: {
    tts: {
      auto: "always",
      provider: "edge",
      edge: {
        voice: "en-US-AvaMultilingualNeural"
      }
    }
  }
}

Observed with the current repo checkout / CLI:

  • node openclaw.mjs daemon status
  • result: Config invalid
  • detail: messages.tts: Unrecognized key: "edge"

Expected

One of these should be true consistently:

  1. Legacy messages.tts.edge is still accepted and migrated to messages.tts.providers.microsoft, or
  2. Docs/types stop advertising messages.tts.edge compatibility and point users only at messages.tts.providers.microsoft.

Evidence in repo

  • src/config/types.tts.ts still defines legacy compat fields edge and microsoft
  • src/config/legacy.migrations.runtime.ts still migrates messages.tts.edge -> messages.tts.providers.microsoft
  • docs/tts.md still says legacy provider: "edge" works and documents Microsoft under providers.microsoft
  • generated config schema only exposes messages.tts.providers.* and does not expose messages.tts.edge

Impact

Upgrades can fail validation for existing local configs that still use the documented legacy messages.tts.edge shape, even though the codebase still implies it should work.

extent analysis

Fix Plan

To resolve the issue, we need to ensure consistency between the documented legacy alias messages.tts.edge and the actual config validation. We will update the config validation to accept messages.tts.edge and migrate it to messages.tts.providers.microsoft.

Steps

  • Update src/config/types.tts.ts to include edge in the config schema.
  • Ensure src/config/legacy.migrations.runtime.ts correctly migrates messages.tts.edge to messages.tts.providers.microsoft.
  • Update docs/tts.md to reflect the supported config options.

Example Code

// src/config/types.tts.ts
interface TtsConfig {
  auto: string;
  provider: string;
  edge?: {
    voice: string;
  };
  providers?: {
    microsoft?: {
      voice: string;
    };
  };
}

// src/config/legacy.migrations.runtime.ts
function migrateConfig(config: any) {
  if (config.messages && config.messages.tts && config.messages.tts.edge) {
    config.messages.tts.providers = config.messages.tts.providers || {};
    config.messages.tts.providers.microsoft = config.messages.tts.edge;
    delete config.messages.tts.edge;
  }
  return config;
}

Verification

To verify the fix, create a config file with the legacy messages.tts.edge shape and run node openclaw.mjs daemon status. The config should be accepted and migrated to messages.tts.providers.microsoft.

Extra Tips

  • Ensure to update the generated config schema to expose messages.tts.edge for backwards compatibility.
  • Consider adding a deprecation notice for the legacy messages.tts.edge shape to encourage users to update to the new messages.tts.providers.microsoft shape.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING