Skip to content

Core command overrides should be merged into the runtime config so custom commands become active #2341

@drwicid

Description

@drwicid

Description

fix.core.commands overrides can be discovered and loaded correctly, but the overridden commands are not activated in the running CLI.

The reason is that startup only merges file overrides for fix.core when building the in-memory CoreConfig. The separate fix.core.commands config is read from the database, but its override file is not merged before the CLI consumes custom_commands.commands. As a result, configs show fix.core.commands can report an active override while the command itself is still unavailable in fixsh.

There was also a secondary presentation bug in the YAML renderer: override annotations assumed list values were already strings. That breaks for custom_commands.commands, which is a list of structured objects. The complete fix therefore has two parts: merge fix.core.commands overrides into the runtime config path, and stringify non-string list override values when rendering config YAML.

The codebase has two different consumers for configuration overrides:

  • ConfigHandlerService merged overrides when configs were read for display or editing.
  • Startup config parsing only merged overrides for fix.core.

That split made the problem easy to miss. The config UI path showed the override correctly, which made the override mechanism look healthy, but the runtime CLI path still used the unmerged command config. Existing tests also covered scalar override comments but did not verify that overridden command definitions were present in the active parsed CoreConfig.

Desired Behavior

  • If an override file named fix.core.commands is present, the overridden commands should be part of the active CLI command set after startup.
  • configs show fix.core.commands and actual CLI behavior should agree.
  • Config YAML generation should succeed for overrides that contain lists of non-string values.
  • Related sub-configs such as fix.core.snapshots should follow the same runtime override semantics.

Version

v4.3.0

Environment

Docker

Steps to Reproduce

  1. Create fix.core.commands.yaml
custom_commands:
  commands:
    - name: my_custom_command
      description: My custom command
      info: My custom command
      template: search is(instance)
      parameters: []

Start fixcore --override-path /home/fixinventory/overrides. Logs indicate successful loading of custom commands.

  1. Test in fixsh -- custom commands are not registered
> my_custom_command
Error: CLIParseError
Message: Command >my_custom_command< is not known. Typo?
  1. Test in fixsh -- presentation bug
> configs show fix.core.commands
Error: TypeError
Message: sequence item 0: expected str instance, dict found

Logs

58:fixcore  | {"timestamp": "2026-03-10T21:44:21", "level": "INFO", "message": "Loading config overrides from: /home/fixinventory/overrides/fix.core.commands.yaml, /home/fixinventory/overrides/fix.worker.yaml", "pid": 28, "thread": "MainThread", "process": "fixcore"}
59-fixcore  | {"timestamp": "2026-03-10T21:44:21", "level": "INFO", "message": "Loaded config overrides for: fix.core.commands, fix.worker", "pid": 28, "thread": "MainThread", "process": "fixcore"}

Additional Context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions