[BUG] ha_config_set_automation (full-config path) silently sorts dict keys alphabetically, breaking sequential variables: references

[Mik13]

💬 What Happened?

I let Claude create an automation. It creates multiple variables, where variable A might reference variable B. The tool gets the correct order (B before A) but writes the variables alphabetically, which creates problem because now A references B which is undefined at that point.

BTW: Thank you for your awesome work!

📋 Copy-Paste from Conversation

## 📋 Bug Description
`ha_config_set_automation` with the full-config path (`config=`) reorders dict keys alphabetically before persisting. Inside a `variables:` block this silently breaks variables that reference earlier variables in the same block.

## 🔄 Steps to Reproduce
1. Call `ha_config_set_automation` (create, no `identifier`) with a `variables:` block whose keys are deliberately NOT in alphabetical order:

   {"actions": [{"variables": {"zzz_erste": "1", "yyy_zweite": "2",
                               "aaa_dritte": "3", "mmm_vierte": "4"}}],
    "alias": "ZZZ TEMP order test",
    "mode": "single",
    "triggers": [{"event_type": "never_fires", "trigger": "event"}]}

2. Call `ha_config_get_automation` on the created automation.
3. Observe the key order in the returned `actions[0].variables`.

## ✅ Expected vs ❌ Actual Behavior

**Expected:**
Key order preserved as submitted: `zzz_erste, yyy_zweite, aaa_dritte, mmm_vierte`. HA renders a `variables:` mapping in insertion order and explicitly supports a later variable referencing an earlier one, so the order is semantically meaningful, not cosmetic.

**Actual:**
Returned sorted alphabetically: `aaa_dritte, mmm_vierte, yyy_zweite, zzz_erste`.

Scope, as narrowed down by testing:
- `config=` (full replacement) → **sorts**
- `python_transform=` → preserves order (verified: a 5-key block submitted as `regen_erwartet, offene_tueren, offene_eg, offene_keller, offene_og` came back unchanged)
- `ha_config_get_automation` read path → preserves order (an automation written in an earlier session still reads back unsorted)

So the sorting happens on the full-config write path only.

**Why this matters — the failure is silent.** In a real automation I had:


variables:
  stunden: "{{ ...weather forecast slice... }}"
  regen_erwartet: "{{ 'ja' if (stunden | selectattr(...) ...) else '' }}"
  offene_tueren: "{{ expand('binary_sensor.group_1') | ... }}"
  meldung: "{% if offene_tueren %}...{% endif %}
            {% if regen_erwartet and offene_og %}...{% endif %}"


After the write, `meldung` was sorted to the **front** of the block, so it rendered against undefined `offene_tueren` / `regen_erwartet`. No error, no log entry — the automation loads and runs, the notification just always takes the empty branch. This would have shipped as a wrong-but-plausible notification if I hadn't diffed the config after writing.

## 💬 Triggering Prompt & Tool Call

**User prompt:** (paraphrased — original was a feature request in German, no relevant detail lost)
"Extend the existing mode with two more stages ... please look at all the automations and think through how best to combine them."

**Tool call(s):**

ha_config_set_automation(
identifier="automation.example_start",
config_hash="<hash>",
config={... "actions": [... {"choose": [... {"sequence": [
{"action": "weather.get_forecasts", "response_variable": "wetter", ...},
{"variables": {
"stunden": "{% ... %}{{ (wetter[...]['forecast'] or [])[:h] }}",
"regen_erwartet": "{{ 'ja' if (stunden | selectattr(...)) else '' }}",
"offene_tueren": "{{ expand('binary_sensor.group_1') | ... }}",
"offene_eg": "{{ expand('binary_sensor.group_2') | ... }}",
"meldung": "{% if offene_tueren %}...{% endif %}..."
}},
{"action": "notify.send_message", "data": {"message": "{{ meldung }}"}, ...}
]} ...]} ...]}
)
→ success

ha_config_get_automation("automation.example_start")
→ variables returned as:
meldung, offene_eg, offene_keller, offene_og, offene_tueren, regen_erwartet, stunden
(alphabetical — meldung now precedes everything it references)


## 🔧 Environment

- **ha-mcp Version:** 7.14.1 (note: 7.14.2 was available at time of report; not yet retested on it)
- **Custom Component:** not detected
- **Installation Method:** addon
- **MCP Transport:** http
- **MCP Client:** unknown (client did not advertise itself)
- **AI Model:** Anthropic Claude — Opus 5
- **Operating System:** Linux 6.18.34-haos-raspi (aarch64)
- **Python Version:** 3.13.12
- **Home Assistant Version:** 2026.7.1
- **Connection Status:** Connected
- **Entity Count:** 1065

## ⚙️ ha-mcp Configuration

- **enable_beta_features:** `False`
- **enable_websocket:** `True`
- **enable_dashboard_partial_tools:** `True`
- **enable_tool_search:** `False`
- **tool_search_max_results:** `5`
- **enable_yaml_config_editing:** `False`
- **enable_filesystem_tools:** `False`
- **enable_code_mode:** `False`
- **enabled_tool_modules:** `all`
- **disabled_tools_count:** `0`
- **pinned_tools_count:** `0`

## 🚨 Error Messages

None — all tool calls returned success. That is the core of the report:
the corruption is silent on both the write and the subsequent read.


## 💡 Additional Context

**Suggested fixes, roughly in order of preference:**

1. Preserve insertion order on the full-config write path — most likely a `sort_keys=True` on a `json.dumps`, or a `sorted()` in a dict-normalisation/hashing helper leaking into the persisted payload. `python_transform` already does the right thing, so the two paths could probably share that serialisation.
2. If sorting is deliberate (e.g. to make `config_hash` order-independent), then sort only for the *hash* computation and persist the original ordering.
3. Failing both: emit a `best_practice_warnings` entry when a `variables:` block contains a key whose template references another key in the same block. That checker already exists for template-vs-native conditions and would have caught this.

**Same class of risk elsewhere:** any tool taking a full config dict where key order carries meaning — worth checking `ha_config_set_script` and `ha_config_set_dashboard` for the same behaviour.

**Workaround for other users:** split interdependent variables into separate consecutive `variables:` steps. Ordering *between* actions is preserved; ordering *within* a dict is not.

[github-actions]

✅ Thanks for the report — this issue has enough information and has been added to the backlog.

🤖 Automated triage by Issue Bot

[Patch76]

Thanks for the isolated reproducer with the deliberately non-alphabetical key block, and for splitting config= against python_transform — that narrowed the search to a single seam.

I could not reproduce the reordering, and tracing the write path end to end shows no place where it could happen server-side.

Live check (add-on install, HTTP transport, HA core-2026.7.4, ha-mcp 7.14.2.dev): created an automation through the config= path with an action-level variables block keyed zzz_erste, yyy_zweite, aaa_dritte, mmm_vierte, then read it back with ha_config_get_automation — same order, unsorted. A second full-config write added a nested block (actions[1].choose[0].sequence[0].variables) keyed www_a, kkk_b, ccc_c, ppp_d, also returned unchanged, so nesting depth is not a factor either. Both were full replacements through config=, the path your report identifies as the sorting one.

Code path. Anchors are at upstream/master; I re-checked the same code at the v7.14.1 tag you reported.

• ha_config_set_automation (src/ha_mcp/tools/tools_config_automations.py:494) passes config through _parse_and_validate_config → parse_json_param (src/ha_mcp/tools/util_helpers.py:125, json.loads or pass-through) and _normalize_automation_config (src/ha_mcp/tools/tools_config_automations.py:88), which works on order-preserving copies and recurses per key. It does contain one deliberate order change, worth naming since it is easy to trip over when probing: a singular root alias is re-inserted under its plural name, which moves it to the end of the root mapping (:145). Nested mappings, including variables, keep their insertion order.
• _upsert_automation (:903) → RestClient.upsert_automation_config (src/ha_mcp/client/rest_client.py:1041) hands the dict to httpx as json=config (:1111). httpx encodes with json.dumps(..., ensure_ascii=False, separators=(",", ":")) — no sort_keys.
• Home Assistant's endpoint validates without substituting: BaseEditConfigView.post in homeassistant/components/config/view.py notes "We just validate, we don't store that data" and writes the raw request body. EditAutomationConfigView._write_value (components/config/automation.py) lifts id, then alias/description/triggers/conditions/actions and their singular aliases, to the front of the root mapping, then updated_value.update(new_value). Nested mappings are untouched.
• The YAML dump is annotatedyaml.dumper.dump, which passes sort_keys=False — annotatedyaml v1.0.2, the version core 2026.7.1 pins; homeassistant/util/yaml/dumper.py is a pure re-export. The two core files above are byte-identical between dev and the 2026.7.1 tag.

Your hypothesis about a sort_keys=True leaking out of a hashing helper was a reasonable one, and the helper does exist: compute_config_hash (src/ha_mcp/utils/config_hash.py:26) serializes with sort_keys=True. It returns a 16-character digest only — no config is ever rebuilt from that serialization, and it is not on the write path. Suggestion (2) is already the implemented behavior.

Two further layers came out clean. The Pydantic argument boundary preserves insertion order for dict[str, Any] on both validate_json and validate_python. The middlewares that touch tool arguments read them without rewriting; the one that does rebuild (src/ha_mcp/strict_bps.py:325) rebuilds only the top-level argument mapping by comprehension, leaving the nested config object by reference.

That points at the layer that produced the JSON-RPC arguments object, above the MCP server — which also fits the asymmetry you measured, since with python_transform the variables dict is constructed inside the server-side sandbox and never crosses the client boundary as a JSON object.

Two things would help pin it down:

1. The MCP client — the report says it did not advertise itself. If it can log the outgoing tool call, the raw arguments JSON for one config= write is the decisive artifact.
2. Whether the alphabetical order is reproducible with a small hand-written config on your setup, or only appeared on the large automation. A model composing a large full replacement can also emit keys in an order of its own choosing, which looks identical from the outside and would not be a serialization bug at all.

The semantics you describe check out independently of where the sort comes from. An action-level variables: step runs through Script._async_step_variables (homeassistant/helpers/script.py:996) into ScriptVariables.async_simple_render (homeassistant/helpers/script_variables.py), which iterates self.variables.items() and writes each rendered value back into the mapping used for the next one: "The rendering happens one at a time, with previous results influencing the next." A forward reference inside one block therefore resolves to undefined, and in a boolean position it takes the empty branch.

One correction to the "no log entry" part, which may give a faster confirmation path than diffing the config: Home Assistant does emit Template variable warning: ... is undefined at WARNING level through LoggingUndefined.__bool__ (homeassistant/helpers/template/__init__.py), and, when a trace element is active for the run, attaches the same message to it via node.add_template_error(...). The write itself is silent, but an automation trace of a run after the write should carry the template error.

Suggestion (3) is the one mitigation that holds regardless of which layer reorders, because the checker sees the block in whatever order it arrives. It would be a new structural check rather than a template-misuse check: variables sits on the best-practice checker's explicit allowlist of legitimate dynamic-data positions and is deliberately not walked by any recursion path (src/ha_mcp/tools/best_practice_checker.py:650, and :47 for the top-level case), so it needs its own pass. The known false-positive class is a name that also exists in an outer scope, where the reference is legal and resolves outward: async_simple_render renders against the incoming run variables, so an earlier key referencing a later sibling picks up the outer value rather than undefined.

On the "same class of risk elsewhere" note: the script, scene and dashboard write paths contain no key reordering either — the only sorted(...) calls in those modules build message text for a warning and a log line. Whatever reorders here would affect every full-config write tool equally, and none of them can restore an order that was already lost before the call arrived.

Your workaround holds and is worth keeping in either case: splitting interdependent variables into consecutive variables: steps is safe, because sequence order is a JSON array and is never affected.

[kingpanther13]

@Mik13 The reordering isn't in ha-mcp — every layer from tool argument to the YAML on disk preserves key order, and the only sort_keys=True near this feeds a hash digest that nothing is rebuilt from. It happened before the call reached the server, which is also why python_transform was clean: that dict is built server-side and never crosses the client boundary. Your workaround holds. One correction — it isn't fully silent: HA logs Template variable warning: ... is undefined and attaches it to the automation trace, so a trace of any run after the write shows it.

Dropping needs-info — the raw arguments JSON would name which layer above the server sorted the keys, but that's not fixable here either way.

@Patch76 four things for the checker, since they're the parts that bite:

1. It needs its own pass — variables is on the allowlist and isn't walked by any recursion path, so there's nothing to hook into.
2. Only compare against later siblings in the same block, not "names that aren't defined yet." Mik13's real automation pulled wetter from an earlier action's response_variable, which is legal and would false-positive on any broader rule.
3. Match identifier tokens, not substrings — a sibling's name appearing inside a string literal or as part of a longer name isn't a reference.
4. Wire it into scripts too, not just automations — tools_config_scripts.py imports the same checker and script variables render one at a time the same way.

The outer-scope false positive you named is real and probably not worth proving — wording the warning to say "unless X is also defined in an outer scope" is cheaper than a scope walk.