Skip to content

Fix #38798: Add v26→27 migration to repair corrupted platform_toolsets - #41006

Closed
iamlukethedev wants to merge 1 commit into
NousResearch:mainfrom
iamlukethedev:fix/38798-config-migration-toolsets
Closed

Fix #38798: Add v26→27 migration to repair corrupted platform_toolsets#41006
iamlukethedev wants to merge 1 commit into
NousResearch:mainfrom
iamlukethedev:fix/38798-config-migration-toolsets

Conversation

@iamlukethedev

@iamlukethedev iamlukethedev commented Jun 7, 2026

Copy link
Copy Markdown
Contributor

Fixes #38798: Config migration (v25->v26) was corrupting platform_toolsets:

  • Valid toolset names like 'hermes-cli' were changed to 'hermes' (invalid)
  • Platform entries (telegram, discord, slack, whatsapp, etc.) were stripped
  • Result: All tools silently stopped working (agent became text-only)

PROBLEM:

  • User had platform_toolsets with 'hermes-cli' and multiple platforms configured
  • During migration, 'hermes-cli' → 'hermes' (wrong toolset name)
  • Platform entries got stripped entirely
  • At runtime, resolve_toolset('hermes') returns empty list
  • System prompt built without any tool guidance
  • Model only does text replies — zero tool calls

SOLUTION:
Add v26→27 migration that:

  1. Detects 'hermes' entries (invalid toolset name)
  2. Repairs them to 'hermes-cli' (correct name)
  3. Validates platform_toolsets structure
  4. Logs which entries were fixed

DEFENSIVE APPROACH:

  • This migration catches corruption from any prior version (25→26 or earlier)
  • Runs on every config that's < v27
  • Identifies invalid toolset names and repairs them
  • Preserves all other entries unchanged
  • Provides clear user feedback on what was repaired

IMPACT:

  • ✅ Tools work after update (agent regains tool-use capability)
  • ✅ platform_toolsets entries are preserved
  • ✅ Users see clear migration message about what was fixed
  • ✅ No manual config editing needed
  • ✅ Works across all update paths (v25→v27, v26→v27, etc.)

Test coverage:

  • 4 new tests verifying toolset name validity
  • 4 new tests validating platform_toolsets structure
  • Tests pass with 0 regressions

Fixes #38798

@iamlukethedev
Fix NousResearch#38798: Add v26→27 migration to repair corrupted plat…
c42864a 
…form_toolsets

Fixes NousResearch#38798: Config migration (v25->v26) was corrupting platform_toolsets:
- Valid toolset names like 'hermes-cli' were changed to 'hermes' (invalid)
- Platform entries (telegram, discord, slack, whatsapp, etc.) were stripped
- Result: All tools silently stopped working (agent became text-only)

PROBLEM:
- User had platform_toolsets with 'hermes-cli' and multiple platforms configured
- During migration, 'hermes-cli' → 'hermes' (wrong toolset name)
- Platform entries got stripped entirely
- At runtime, resolve_toolset('hermes') returns empty list
- System prompt built without any tool guidance
- Model only does text replies — zero tool calls

SOLUTION:
Add v26→27 migration that:
1. Detects 'hermes' entries (invalid toolset name)
2. Repairs them to 'hermes-cli' (correct name)
3. Validates platform_toolsets structure
4. Logs which entries were fixed

DEFENSIVE APPROACH:
- This migration catches corruption from any prior version (25→26 or earlier)
- Runs on every config that's < v27
- Identifies invalid toolset names and repairs them
- Preserves all other entries unchanged
- Provides clear user feedback on what was repaired

IMPACT:
- ✅ Tools work after update (agent regains tool-use capability)
- ✅ platform_toolsets entries are preserved
- ✅ Users see clear migration message about what was fixed
- ✅ No manual config editing needed
- ✅ Works across all update paths (v25→v27, v26→v27, etc.)

Test coverage:
- 4 new tests verifying toolset name validity
- 4 new tests validating platform_toolsets structure
- Tests pass with 0 regressions

Fixes NousResearch#38798
@alt-glitch alt-glitch added type/bug Something isn't working comp/cli CLI entry point, hermes_cli/, setup wizard area/config Config system, migrations, profiles P2 Medium — degraded but workaround exists labels Jun 7, 2026
@kshitijk4poor kshitijk4poor mentioned this pull request Jun 26, 2026
Merged
kshitijk4poor pushed a commit that referenced this pull request Jun 26, 2026
@lEWFkRAD @kshitijk4poor
fix(config): surface invalid platform_toolsets instead of silently dr…
41ede84 
…opping tools (#38798)

A config migration (or hand-edit) that leaves an invalid toolset name in
`platform_toolsets` — e.g. the #38798 corruption that rewrote `hermes-cli` to
the non-existent `hermes` — silently disabled all affected tools:
resolve_toolset() returns [] for an unknown name, so the agent quietly lost its
tools with no error, warning, or log entry and degraded to text-only replies.

Surface it loudly at two points:
- After migration (migrate_config): validate platform_toolsets and record/print
  a warning per unknown name, with a `hermes-<platform>` suggestion when that
  would have been valid (the exact #38798 shape).
- At runtime (_get_platform_tools): if a platform was explicitly configured but
  every toolset name is invalid, log a warning when tools are resolved for a
  session — so an ALREADY-corrupted config is caught at startup, not only on the
  next `hermes update`.

Logic lives in a new pure, side-effect-free helper (toolset_validation.py) with
validate_toolset injected, so it is unit-testable without the tool registry.

Note: the original v25→v26 migration that caused the corruption no longer
exists (config format is now v30; no migration step rewrites toolset names).
This change is the durable defense against the silent-failure mode regardless
of cause, matching the issue's "Expected: log a warning".

Salvaged from #39207 by @lEWFkRAD (authorship preserved via cherry-pick).
Tests: 9 helper cases (incl. the #38798 corruption shape, mixed valid/invalid,
zero-tools state, non-dict/scalar/non-string) + a runtime caplog test — both the
helper warning and the runtime guard mutation-verified to fail without the fix.

Closes #38798. Supersedes #39581 (prevent-in-v25→v26 — that path is gone),
#41006 / #40208 (repair-migration for already-corrupted configs).
@kshitijk4poor

kshitijk4poor commented Jun 26, 2026

Copy link
Copy Markdown
Collaborator

Thanks @iamlukethedev — closing in favor of #52920 (#38798). Your v26→v27 repair migration would auto-fix configs already corrupted back in May; #52920 takes the detection-not-repair route (warn loudly at migration + runtime) since the corruption source is gone on main and the affected population is small (users corrupted pre-v26 who never reconfigured). An auto-repair migration remains a reasonable low-priority follow-up if we see it in the wild — your PR is a good reference for that. Appreciate it!

pai-scaffolde pushed a commit to pai-scaffolde/hermes-agent that referenced this pull request Jun 28, 2026
@lEWFkRAD @pai-scaffolde
fix(config): surface invalid platform_toolsets instead of silently dr…
1276c99 
…opping tools (NousResearch#38798)

A config migration (or hand-edit) that leaves an invalid toolset name in
`platform_toolsets` — e.g. the NousResearch#38798 corruption that rewrote `hermes-cli` to
the non-existent `hermes` — silently disabled all affected tools:
resolve_toolset() returns [] for an unknown name, so the agent quietly lost its
tools with no error, warning, or log entry and degraded to text-only replies.

Surface it loudly at two points:
- After migration (migrate_config): validate platform_toolsets and record/print
  a warning per unknown name, with a `hermes-<platform>` suggestion when that
  would have been valid (the exact NousResearch#38798 shape).
- At runtime (_get_platform_tools): if a platform was explicitly configured but
  every toolset name is invalid, log a warning when tools are resolved for a
  session — so an ALREADY-corrupted config is caught at startup, not only on the
  next `hermes update`.

Logic lives in a new pure, side-effect-free helper (toolset_validation.py) with
validate_toolset injected, so it is unit-testable without the tool registry.

Note: the original v25→v26 migration that caused the corruption no longer
exists (config format is now v30; no migration step rewrites toolset names).
This change is the durable defense against the silent-failure mode regardless
of cause, matching the issue's "Expected: log a warning".

Salvaged from NousResearch#39207 by @lEWFkRAD (authorship preserved via cherry-pick).
Tests: 9 helper cases (incl. the NousResearch#38798 corruption shape, mixed valid/invalid,
zero-tools state, non-dict/scalar/non-string) + a runtime caplog test — both the
helper warning and the runtime guard mutation-verified to fail without the fix.

Closes NousResearch#38798. Supersedes NousResearch#39581 (prevent-in-v25→v26 — that path is gone),
NousResearch#41006 / NousResearch#40208 (repair-migration for already-corrupted configs).
waefrebeorn pushed a commit to waefrebeorn/slermes that referenced this pull request Jul 2, 2026
@lEWFkRAD @kshitijk4poor
fix(config): surface invalid platform_toolsets instead of silently dr…
a0f2227 
…opping tools (NousResearch#38798)

A config migration (or hand-edit) that leaves an invalid toolset name in
`platform_toolsets` — e.g. the NousResearch#38798 corruption that rewrote `hermes-cli` to
the non-existent `hermes` — silently disabled all affected tools:
resolve_toolset() returns [] for an unknown name, so the agent quietly lost its
tools with no error, warning, or log entry and degraded to text-only replies.

Surface it loudly at two points:
- After migration (migrate_config): validate platform_toolsets and record/print
  a warning per unknown name, with a `hermes-<platform>` suggestion when that
  would have been valid (the exact NousResearch#38798 shape).
- At runtime (_get_platform_tools): if a platform was explicitly configured but
  every toolset name is invalid, log a warning when tools are resolved for a
  session — so an ALREADY-corrupted config is caught at startup, not only on the
  next `hermes update`.

Logic lives in a new pure, side-effect-free helper (toolset_validation.py) with
validate_toolset injected, so it is unit-testable without the tool registry.

Note: the original v25→v26 migration that caused the corruption no longer
exists (config format is now v30; no migration step rewrites toolset names).
This change is the durable defense against the silent-failure mode regardless
of cause, matching the issue's "Expected: log a warning".

Salvaged from NousResearch#39207 by @lEWFkRAD (authorship preserved via cherry-pick).
Tests: 9 helper cases (incl. the NousResearch#38798 corruption shape, mixed valid/invalid,
zero-tools state, non-dict/scalar/non-string) + a runtime caplog test — both the
helper warning and the runtime guard mutation-verified to fail without the fix.

Closes NousResearch#38798. Supersedes NousResearch#39581 (prevent-in-v25→v26 — that path is gone),
NousResearch#41006 / NousResearch#40208 (repair-migration for already-corrupted configs).
habarmc1223-sudo pushed a commit to habarmc1223-sudo/hermes-agent-fluxmem that referenced this pull request Jul 8, 2026
@lEWFkRAD @kshitijk4poor
fix(config): surface invalid platform_toolsets instead of silently dr…
f965f9f 
…opping tools (NousResearch#38798)

A config migration (or hand-edit) that leaves an invalid toolset name in
`platform_toolsets` — e.g. the NousResearch#38798 corruption that rewrote `hermes-cli` to
the non-existent `hermes` — silently disabled all affected tools:
resolve_toolset() returns [] for an unknown name, so the agent quietly lost its
tools with no error, warning, or log entry and degraded to text-only replies.

Surface it loudly at two points:
- After migration (migrate_config): validate platform_toolsets and record/print
  a warning per unknown name, with a `hermes-<platform>` suggestion when that
  would have been valid (the exact NousResearch#38798 shape).
- At runtime (_get_platform_tools): if a platform was explicitly configured but
  every toolset name is invalid, log a warning when tools are resolved for a
  session — so an ALREADY-corrupted config is caught at startup, not only on the
  next `hermes update`.

Logic lives in a new pure, side-effect-free helper (toolset_validation.py) with
validate_toolset injected, so it is unit-testable without the tool registry.

Note: the original v25→v26 migration that caused the corruption no longer
exists (config format is now v30; no migration step rewrites toolset names).
This change is the durable defense against the silent-failure mode regardless
of cause, matching the issue's "Expected: log a warning".

Salvaged from NousResearch#39207 by @lEWFkRAD (authorship preserved via cherry-pick).
Tests: 9 helper cases (incl. the NousResearch#38798 corruption shape, mixed valid/invalid,
zero-tools state, non-dict/scalar/non-string) + a runtime caplog test — both the
helper warning and the runtime guard mutation-verified to fail without the fix.

Closes NousResearch#38798. Supersedes NousResearch#39581 (prevent-in-v25→v26 — that path is gone),
NousResearch#41006 / NousResearch#40208 (repair-migration for already-corrupted configs).
santhreal pushed a commit to santhreal/hermes-agent that referenced this pull request Jul 13, 2026
@lEWFkRAD @kshitijk4poor
fix(config): surface invalid platform_toolsets instead of silently dr…
f1326af 
…opping tools (NousResearch#38798)

A config migration (or hand-edit) that leaves an invalid toolset name in
`platform_toolsets` — e.g. the NousResearch#38798 corruption that rewrote `hermes-cli` to
the non-existent `hermes` — silently disabled all affected tools:
resolve_toolset() returns [] for an unknown name, so the agent quietly lost its
tools with no error, warning, or log entry and degraded to text-only replies.

Surface it loudly at two points:
- After migration (migrate_config): validate platform_toolsets and record/print
  a warning per unknown name, with a `hermes-<platform>` suggestion when that
  would have been valid (the exact NousResearch#38798 shape).
- At runtime (_get_platform_tools): if a platform was explicitly configured but
  every toolset name is invalid, log a warning when tools are resolved for a
  session — so an ALREADY-corrupted config is caught at startup, not only on the
  next `hermes update`.

Logic lives in a new pure, side-effect-free helper (toolset_validation.py) with
validate_toolset injected, so it is unit-testable without the tool registry.

Note: the original v25→v26 migration that caused the corruption no longer
exists (config format is now v30; no migration step rewrites toolset names).
This change is the durable defense against the silent-failure mode regardless
of cause, matching the issue's "Expected: log a warning".

Salvaged from NousResearch#39207 by @lEWFkRAD (authorship preserved via cherry-pick).
Tests: 9 helper cases (incl. the NousResearch#38798 corruption shape, mixed valid/invalid,
zero-tools state, non-dict/scalar/non-string) + a runtime caplog test — both the
helper warning and the runtime guard mutation-verified to fail without the fix.

Closes NousResearch#38798. Supersedes NousResearch#39581 (prevent-in-v25→v26 — that path is gone),
NousResearch#41006 / NousResearch#40208 (repair-migration for already-corrupted configs).
Gravezzz pushed a commit to Gravezzz/hermes-agent that referenced this pull request Jul 21, 2026
@lEWFkRAD @kshitijk4poor
fix(config): surface invalid platform_toolsets instead of silently dr…
db0685d 
…opping tools (NousResearch#38798)

A config migration (or hand-edit) that leaves an invalid toolset name in
`platform_toolsets` — e.g. the NousResearch#38798 corruption that rewrote `hermes-cli` to
the non-existent `hermes` — silently disabled all affected tools:
resolve_toolset() returns [] for an unknown name, so the agent quietly lost its
tools with no error, warning, or log entry and degraded to text-only replies.

Surface it loudly at two points:
- After migration (migrate_config): validate platform_toolsets and record/print
  a warning per unknown name, with a `hermes-<platform>` suggestion when that
  would have been valid (the exact NousResearch#38798 shape).
- At runtime (_get_platform_tools): if a platform was explicitly configured but
  every toolset name is invalid, log a warning when tools are resolved for a
  session — so an ALREADY-corrupted config is caught at startup, not only on the
  next `hermes update`.

Logic lives in a new pure, side-effect-free helper (toolset_validation.py) with
validate_toolset injected, so it is unit-testable without the tool registry.

Note: the original v25→v26 migration that caused the corruption no longer
exists (config format is now v30; no migration step rewrites toolset names).
This change is the durable defense against the silent-failure mode regardless
of cause, matching the issue's "Expected: log a warning".

Salvaged from NousResearch#39207 by @lEWFkRAD (authorship preserved via cherry-pick).
Tests: 9 helper cases (incl. the NousResearch#38798 corruption shape, mixed valid/invalid,
zero-tools state, non-dict/scalar/non-string) + a runtime caplog test — both the
helper warning and the runtime guard mutation-verified to fail without the fix.

Closes NousResearch#38798. Supersedes NousResearch#39581 (prevent-in-v25→v26 — that path is gone),
NousResearch#41006 / NousResearch#40208 (repair-migration for already-corrupted configs).
leewenjie pushed a commit to leewenjie/hermes-agent that referenced this pull request Aug 7, 2026
@lEWFkRAD @kshitijk4poor
fix(config): surface invalid platform_toolsets instead of silently dr…
0281509 
…opping tools (NousResearch#38798)

A config migration (or hand-edit) that leaves an invalid toolset name in
`platform_toolsets` — e.g. the NousResearch#38798 corruption that rewrote `hermes-cli` to
the non-existent `hermes` — silently disabled all affected tools:
resolve_toolset() returns [] for an unknown name, so the agent quietly lost its
tools with no error, warning, or log entry and degraded to text-only replies.

Surface it loudly at two points:
- After migration (migrate_config): validate platform_toolsets and record/print
  a warning per unknown name, with a `hermes-<platform>` suggestion when that
  would have been valid (the exact NousResearch#38798 shape).
- At runtime (_get_platform_tools): if a platform was explicitly configured but
  every toolset name is invalid, log a warning when tools are resolved for a
  session — so an ALREADY-corrupted config is caught at startup, not only on the
  next `hermes update`.

Logic lives in a new pure, side-effect-free helper (toolset_validation.py) with
validate_toolset injected, so it is unit-testable without the tool registry.

Note: the original v25→v26 migration that caused the corruption no longer
exists (config format is now v30; no migration step rewrites toolset names).
This change is the durable defense against the silent-failure mode regardless
of cause, matching the issue's "Expected: log a warning".

Salvaged from NousResearch#39207 by @lEWFkRAD (authorship preserved via cherry-pick).
Tests: 9 helper cases (incl. the NousResearch#38798 corruption shape, mixed valid/invalid,
zero-tools state, non-dict/scalar/non-string) + a runtime caplog test — both the
helper warning and the runtime guard mutation-verified to fail without the fix.

Closes NousResearch#38798. Supersedes NousResearch#39581 (prevent-in-v25→v26 — that path is gone),
NousResearch#41006 / NousResearch#40208 (repair-migration for already-corrupted configs).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

area/config Config system, migrations, profiles comp/cli CLI entry point, hermes_cli/, setup wizard P2 Medium — degraded but workaround exists type/bug Something isn't working

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

bug: config migration (v25->v26) corrupts platform_toolsets, silently kills all tools

3 participants

@iamlukethedev @kshitijk4poor @alt-glitch