Feature request: durable, resumable batch deployments with validation and atomic cutover for native automations

[jasonobrown]

Summary

Please add an application-level deployment/job API that lets an MCP client submit a multi-step Hubitat native-automation migration as one durable, idempotent plan.

The server should:

• stage new Rule Machine rules and other native apps while paused or otherwise inactive;
• persist progress and checkpoints on the hub;
• expose compact status and detailed audit logs;
• validate the complete staged dependency graph;
• perform an explicit atomic cutover only after validation succeeds; and
• automatically roll back, or provide a deterministic rollback operation, if any cutover step fails.

This is not merely a request for JSON-RPC batch-array support. It is a request for a server-side orchestration layer tailored to Hubitat Rule Machine and classic native apps.

Relationship to existing completed work

This request builds on, but is distinct from, two completed issues:

• [feature] chunked / resumable bulk rule authoring — avoid timeout + partial-bake on large addActions bundles #284 added or proposed chunked/resumable bulk authoring for a single Rule Machine rule so a large addActions bundle does not time out or remain partially baked.
• Slow tool calls die over the cloud relay (~10s ceiling): idempotency tokens + response replay so writes survive for remote users #348 addressed idempotency and result replay for individual slow write operations that may complete after the cloud relay drops the response.

Those capabilities are important prerequisites. The remaining gap is a durable transaction-like workflow spanning multiple rules, native apps, Button Controllers, child Button Rules, caller retargeting, validation gates, production cutover, and rollback. A client should not have to retain and reconstruct that entire migration state across dozens of separate calls.

Problem

Complex native-automation changes currently require many separate MCP round trips because Rule Machine authoring is driven through a stateful wizard. A client often has to:

1. navigate to the correct page;
2. start a trigger or action wizard;
3. write one field;
4. re-read the schema because the next field is exposed dynamically;
5. write the next field;
6. commit the action;
7. read back the rendered configuration;
8. run a health check; and
9. repeat for every trigger, action, rule, caller, and supporting app.

For a migration involving a controller rule, supporting rules, required expressions, Button Controller children, caller retargeting, and a final old-to-new cutover, this can require dozens of successful MCP calls.

The client or agent session can end or disconnect before the workflow is complete. The resulting state may include:

• several correctly paused staged rules;
• partially authored or superseded drafts;
• completed operations that the next client turn must rediscover;
• callers still pointing to the old rule;
• no durable record of the intended final topology; and
• no safe, single operation that validates and commits the migration.

There are also normal Hubitat wire-format behaviors that increase orchestration cost. For example, a multi-select value may be accepted and stored in a normalized form even when a tool response reports a value mismatch. A robust deployment layer should verify the final readback and classify normalization as a warning rather than forcing the client to reconstruct the workflow manually.

Representative use case, intentionally sanitized

A user wants to replace an existing automation without modifying or deleting the original until the replacement is proven safe. The migration requires:

• cloning a main Rule Machine controller;
• creating several support rules;
• adding required expressions and hub variables;
• cloning a Button Controller with child Button Rules;
• retargeting selected child actions from an old rule to a new rule;
• keeping all replacements inactive during construction;
• validating rule health, subscriptions, scheduled jobs, and caller/callee relationships;
• pausing the old automation set; and
• activating the replacement set as one controlled cutover.

No live device command should be sent during staging or validation.

The current low-level tools can perform the individual steps, but the MCP client must coordinate the entire transaction and retain all state across many calls. That is fragile for long-running agent workflows.

Proposed tool surface

Names are illustrative and should follow the project’s existing conventions.

hub_create_deployment

Creates a durable deployment plan and returns a jobId quickly.

Suggested inputs:

• name
• idempotencyKey
• description
• createHubBackup
• stageInactive
• allowDeviceCommands, default false
• operations
• validations
• cutover
• rollbackOnFailure
• confirm
• existing best-practice acknowledgment key, where applicable

hub_get_deployment_status

Returns compact progress for polling without replaying large Rule Machine configurations.

hub_resume_deployment

Continues a paused, interrupted, or restart-recovered deployment from its last committed checkpoint.

hub_validate_deployment

Runs all configured validation gates without changing the active production topology.

hub_commit_deployment

Performs the validated cutover. It should require the expected plan hash or confirmation token returned by validation so that a stale client cannot commit a changed plan.

hub_rollback_deployment

Restores the pre-deployment topology and any rule/app snapshots associated with the job.

hub_cancel_deployment

Cancels an uncommitted deployment and optionally removes only the staged artifacts created by that job.

Durable execution model

A single blocking Groovy execution may also have practical limits, so the implementation should be a persistent state machine, not necessarily one giant synchronous request.

Recommended behavior:

1. hub_create_deployment validates the manifest, persists it, and returns a jobId.
2. A bounded worker processes a safe number of operations per invocation.
3. The worker checkpoints after every successful operation.
4. Long work is continued with Hubitat scheduling, or by subsequent resume or status calls.
5. A client disconnect does not lose the job state.
6. A hub or MCP-app restart can recover the deployment from the last checkpoint.
7. Retrying the same idempotencyKey returns the existing job instead of creating duplicate rules or apps.

Suggested phases:

• draft
• planning
• staging
• validating
• ready_for_commit
• committing
• completed
• failed
• rolling_back
• rolled_back
• cancelled

A per-hub deployment lock should prevent concurrent jobs from editing the same Rule Machine or Button Controller objects.

Declarative operation types

The deployment manifest should support aliases so later operations can reference newly created app IDs without the client having to stop and read them back.

Suggested operations:

• create a whole-hub backup;
• create a Rule Machine rule;
• clone a Rule Machine rule;
• import a native-app export bundle;
• create or clone another supported native app;
• add, remove, modify, or replace triggers;
• add, remove, move, or replace actions;
• add or replace required expressions;
• add or remove local variables;
• create or update hub variables;
• patch a rule or app using the existing structured shortcuts;
• create or clone a Button Controller;
• create or patch child Button Rules;
• retarget a Run Actions reference from one rule alias or ID to another;
• pause, resume, enable, or disable an app;
• stop in-progress actions or timers when explicitly requested;
• validate a staged object;
• remove staged artifacts created by the job; and
• restore a captured rule/app snapshot.

Example alias flow:

{
  "op": "cloneRule",
  "sourceAppId": "<existing-rule-id>",
  "alias": "replacement-controller",
  "newName": "Replacement Controller"
}

A later operation can use:

{
  "op": "retargetRuleAction",
  "appId": "<staged-button-rule-id>",
  "fromRuleId": "<existing-rule-id>",
  "toRule": { "alias": "replacement-controller" }
}

Example sanitized deployment request

{
  "name": "native-automation-migration",
  "idempotencyKey": "native-automation-migration-v1",
  "createHubBackup": true,
  "stageInactive": true,
  "allowDeviceCommands": false,
  "operations": [
    {
      "op": "cloneRule",
      "sourceAppId": "<old-controller-id>",
      "alias": "new-controller",
      "newName": "Replacement Controller"
    },
    {
      "op": "createRule",
      "alias": "new-wrapper",
      "name": "Replacement Trigger Wrapper",
      "spec": {
        "triggers": [],
        "actions": []
      }
    },
    {
      "op": "cloneNativeApp",
      "sourceAppId": "<old-button-controller-id>",
      "alias": "new-button-controller",
      "newName": "Replacement Button Controller"
    },
    {
      "op": "retargetRuleAction",
      "appId": "<staged-button-rule-id>",
      "fromRuleId": "<old-controller-id>",
      "toRule": { "alias": "new-wrapper" }
    }
  ],
  "validations": {
    "ruleHealth": true,
    "renderedConfig": true,
    "eventSubscriptions": true,
    "scheduledJobs": true,
    "dependencyGraph": true,
    "noDuplicateActiveCallers": true,
    "expectedTopology": true
  },
  "cutover": {
    "pause": [
      "<old-controller-id>",
      "<old-support-rule-id>"
    ],
    "resume": [
      { "alias": "new-wrapper" },
      "<new-support-rule-id>"
    ],
    "keepCalledOnlyRulesPaused": [
      { "alias": "new-controller" }
    ]
  },
  "rollbackOnFailure": true
}

Validation requirements

Before a deployment becomes ready_for_commit, the server should verify at least:

1. Every staged Rule Machine rule has a healthy compiled state.
2. The rendered configuration contains no broken trigger, action, or condition markers.
3. No action block is left in a partial wizard-commit state.
4. Required expressions are present and resolve to the expected devices, modes, or variables.
5. Event subscriptions and scheduled jobs match the staged plan.
6. Caller/callee references resolve to the expected app IDs or aliases.
7. Button Controller children reference the intended replacement rules.
8. No staged rule is active unless the manifest explicitly permits it.
9. No old and new rule pair would create duplicate active triggers or competing device commands after cutover.
10. Hubitat’s asynchronous writes have settled and a final readback matches the manifest.
11. Multi-select normalization is distinguished from a true rejected write.
12. The pre-cutover backup and all rule/app snapshots are still available.

The validation result should return a plan hash or confirmation token. hub_commit_deployment should reject a token if the deployment manifest or any staged object has changed since validation.

Atomic cutover and rollback semantics

The cutover should behave transactionally from the user’s perspective:

1. Confirm every staged object is inactive and healthy.
2. Capture the current active/paused/disabled topology.
3. Pause or disable the old set.
4. Activate the new set in the declared order.
5. Re-read the final topology and dependency graph.
6. Mark the deployment complete only if every expected state matches.
7. If any step fails, restore the old topology and deactivate the new set.

Where true database atomicity is unavailable, the server should implement compensating actions and make the rollback result explicit.

Safety and privacy requirements

• allowDeviceCommands should default to false during staging, validation, and dry runs.
• Running rule actions should require an explicit operation and confirmation.
• Existing backup and best-practice safety gates should remain in force.
• Destructive cleanup should affect only artifacts recorded as created by that deployment.
• Status and audit logs should redact access tokens, hub URLs, credentials, location data, and other sensitive values.
• The response should not echo full app settings when a compact summary is sufficient.
• A dry-run or plan-only mode should be available before any write.

Status response

A compact status shape would reduce MCP context consumption:

{
  "jobId": "deployment-123",
  "state": "staging",
  "phase": "retarget-callers",
  "completedOperations": 12,
  "totalOperations": 18,
  "currentOperation": "retargetRuleAction",
  "backupKey": "<redacted-or-opaque-handle>",
  "warnings": 1,
  "errors": 0,
  "confirmationRequired": false,
  "nextAction": "poll"
}

Detailed operation logs and before/after manifests could be written to File Manager and retrieved separately with pagination or cursors.

Dry run and planning

Please include a plan-only mode that reports:

• operations that would run;
• objects that would be created or changed;
• active rules that would be paused;
• staged rules that would be activated;
• caller references that would be retargeted;
• device commands that could occur, if any;
• missing permissions or safety prerequisites;
• name or alias collisions; and
• the expected rollback plan.

Acceptance criteria

1. An MCP client can submit a complete multi-rule/native-app migration in one declarative request.
2. The server returns a durable jobId and persists progress independently of the client session.
3. Retrying the same idempotency key never creates duplicate staged apps.
4. The deployment can resume after a client disconnect or hub/MCP-app restart.
5. All new rules/apps remain inactive during staging unless explicitly declared otherwise.
6. The old production topology remains untouched until validation succeeds and commit is explicitly authorized.
7. A compact status call reports deterministic progress and the next required action.
8. The server can retarget Rule Machine and Button Rule caller references using aliases.
9. Benign Hubitat value normalization is handled by verified readback rather than treated as an unrecoverable failure.
10. Commit either produces the exact declared topology or performs a documented rollback.
11. No device command is issued during staging or validation when allowDeviceCommands is false.
12. The deployment produces an audit record containing the plan, checkpoints, validation results, cutover result, and rollback result without sensitive data.

Optional follow-on: deployment bundles

A useful extension would be export/import of a complete deployment bundle containing:

• the declarative manifest;
• native app exports;
• alias mappings;
• validation policy;
• expected topology; and
• rollback metadata.

This would make complex automation migrations portable, reviewable, testable, and much less dependent on a single long-lived AI-client execution window.

Privacy note

The representative examples above are intentionally sanitized. They contain no personal names, email addresses, local or public IP addresses, hub identifiers, endpoint URLs, access tokens, household device labels, location data, actual production app IDs, screenshots, or private repository information.

[kingpanther13]

Are you on the most up to date version? I'm digging into this but I'm not sure if what you're proposing is possible or plausible. A lot of what you're asking for already exists, it's just driven by the mcp client... I'm just not sure if doing anything server side would really be possible or if it would make a difference. To be clear, the visual rule builder is considered the primary rule machine thing for us, since it uses a newer flow in Hubitat it's possible of doing pretty much everything you would need for something like button controllers, you'd just need to transfer stuff over to it if you have existing rules/automations to modify. Everything is already backed up before getting modified as well, or should be anyways.

I'll play around with this but I'm pretty sure we already have this functionality just not server side, which is intentional for the most part

[jasonobrown]

Thanks for digging into it. A few clarifications that may help narrow the request.

First: yes, this is on the current version. I just verified the live connector reports MCP Rule Server 3.7.0, and the current repository packageManifest.json is also 3.7.0.

Second, and probably the most important context: I am using regular ChatGPT in the normal Chat UI with this MCP tool attached. I am not running Codex or another long-running/persistent agent. That distinction is what exposed the problem.

The server's existing primitives work well individually, and I agree that much of the orchestration can theoretically be client-driven. The practical failure mode I hit is that a normal ChatGPT turn has a finite tool-execution window. A migration involving several existing Rule Machine rules plus Button Controller children required many read → wizard-step → readback → health-check calls. ChatGPT repeatedly reached the end of its turn before the complete staged migration/cutover was finished. The next turn could continue, but it had to reconstruct progress from the hub and there was no single durable deployment object saying exactly what had been completed, what was still staged, and what constituted the final cutover.

So the gap I am trying to describe is not primarily "Rule Machine needs another way to author one rule", and backups were not the issue. The MCP server was already backing up edits correctly. Issues #284/#348 also appear to cover the lower-level timeout/idempotency problems well.

The remaining pain point is the multi-object transaction/orchestration boundary when the MCP client is an ordinary chat session rather than a persistent agent.

A concrete but privacy-neutral example of the workflow was roughly:

1. Inspect several existing native automations and their callers/dependencies.
2. Clone originals and keep them untouched.
3. Build replacement rules while paused.
4. Clone a Button Controller with its child Button Rules and retarget selected children.
5. Validate each replacement's rendered configuration and health.
6. Verify caller/callee references and expected paused/active topology.
7. Only after all validation passes, pause the old set and activate the replacement set as one cutover.
8. Verify the resulting topology and roll back if the cutover validation fails.

All of those operations are possible today, but in regular ChatGPT they can span enough MCP calls that the client turn ends before step 7. Client-side state alone is therefore fragile: the next ChatGPT turn has conversation history, but it does not have a durable execution job/checkpoint managed by the tool.

I am not attached to the exact server-side API proposed in the original issue if that is the wrong architecture. A smaller implementation would solve the actual problem if it gave a normal MCP client a durable unit of work. For example, something along these lines would be sufficient:

• submit/store a deployment plan (or create a deployment/checkpoint record),
• return a deployment/job ID,
• allow subsequent ChatGPT turns to ask status and resume from the next unapplied step,
• make each step idempotent,
• keep replacement automations inactive until an explicit commit/cutover step,
• validate expected state before commit,
• record enough before/after state to perform a compensating rollback if the cutover only partially succeeds.

The server would not necessarily need to run the whole migration asynchronously in one background task. Persisting the plan/checkpoint and enforcing idempotent staged/commit semantics would already remove most of the problem, while ChatGPT could continue driving individual operations across multiple turns.

On Visual Rule Builder: I understand that VRB is the preferred direction and that it can represent most/all of the needed logic. In this case, though, the task involved modifying an existing installation made up of native Rule Machine and Button Controller automations. Migrating those automations to VRB as a prerequisite would be a substantially larger behavioral migration than the repair itself. For new automation work, using VRB where appropriate makes sense; I don't think it fully addresses the orchestration/checkpoint issue for maintaining an existing RM/Button Controller estate from regular ChatGPT.

So I would summarize the request more narrowly as:

Can the MCP server expose a durable, resumable, idempotent deployment/checkpoint abstraction for multi-app changes, so a non-persistent MCP client such as regular ChatGPT can safely stage and commit a migration across multiple chat turns?

If the intended answer is that this should stay entirely client-side, that is useful too. In that case, I would be interested in what client-side mechanism you recommend for a normal ChatGPT MCP session to persist an authoritative deployment plan/checkpoint across turns without relying on an agent runtime such as Codex.

[kingpanther13]

Yeah I think we already have what you're describing. the optoken feature, which I believe should be on by default, basically saves progress as tools move along. It was designed specifically because the cloud relay has 10 second timeouts per tool call. Additionally it should back up individual rules and whatnot before it makes any changes.

It sounds like your chatgpt was skipping the easy path and using the fallback/walkstep path which is a lot more context/token heavy.

Either way, I'm working on some optimizations right now either way that should improve how things work and require less tool calls.

[jasonobrown]

Thank you — that explanation helps, and I think your diagnosis is probably right about a major part of what happened.

Looking back at the actual session, regular ChatGPT was doing a large number of walkStep operations and page/schema readbacks. That was clearly the expensive path, and it likely accounts for most of the context/tool-call growth. I appreciate you pointing out that the structured path should have been preferred, and the optimizations you are working on sound directly relevant.

I also agree that opToken plus the existing per-object backups already cover important parts of the safety problem, especially relay timeouts, partial progress within a single large write, and duplicate-commit protection.

One detail that may help explain the client behavior: in the regular ChatGPT tool surface I was seeing, the obvious callable gateway was manage_native_rules_and_apps -> update_native_app, whose schema exposed raw settings/button operations and walkStep. The documented structured hub_set_rule / hub_manage_rule_machine path was not obvious in the callable tools ChatGPT selected. That may be a tool-discovery or description issue rather than missing server functionality.

Similarly, the live schema presented opToken as an optional caller-supplied value, and the calls ChatGPT made did not include one. I may be misunderstanding what “on by default” means internally. If the server already assigns one automatically, then that is good and I may simply not be seeing it. If the client is expected to invent and pass it, stronger tool-description guidance for ordinary ChatGPT would probably help ensure it is consistently used.

So I am comfortable narrowing the issue substantially:

• make the structured/bundled path the clearly preferred and discoverable route for regular ChatGPT;
• steer the model away from walkStep unless the structured operation cannot represent the change;
• make opToken use automatic or very hard for the client to miss;
• return compact resume/progress information when a bundled operation pauses.

If those changes make the original multi-rule workflow complete in far fewer calls, that may resolve the practical problem without needing the broader deployment abstraction I initially proposed. I am happy to test the optimized version in regular ChatGPT once it is available and report whether the same workflow can finish cleanly.

Thanks again for taking the time to investigate it.

[kingpanther13]

@jasonobrown Take a look at #377 (already merged) and #388 which should be getting merged soon. Let me know if that fulfills what you're looking for. This issue lead me to do a major rework which should alleviate most of the cloud relay problems and make things work better overall, and hopefully remove the need for more complicated backups/restores.

[jasonobrown]

Thank you for following up, and for putting this much work into the underlying problem. I reviewed both #377 and #388.

#377 directly addresses several of the expensive multi-object steps that came up in the original workflow: batch pause/resume, one-step retargeting of rule actions, and staging clones/imports disabled—including their child apps. Those changes should remove a large number of the individual calls regular ChatGPT was making.

#388 appears to address the other major part of the problem: long writes crossing the cloud-relay boundary. Using the standard MCP requestState continuation flow, detached workers for indivisible Rule Machine/native-app work, duplicate prevention, and terminal result replay looks like a cleaner and more general solution than the custom deployment/checkpoint API I initially proposed.

So, based on the designs and testing described in those PRs, yes—this appears to fulfill the practical intent of #376, and likely with a better architecture than my original suggestion.

The requirement I was trying to solve was specifically for regular ChatGPT in the normal Chat UI using the MCP connector—not Codex or another persistent agent—to complete a complex staged migration without falling into a very long sequence of walkStep calls, exhausting the chat turn, or requiring manual reconstruction from partially completed state and backups. These changes appear targeted at exactly those failure modes.

I would only reserve final confirmation until #388 is merged and both changes are available in an HPM release, so I can repeat the unfinished workflow in the same regular-ChatGPT environment that exposed the issue. Please let me know which released version contains both changes. Once I can test it, I’ll report back; if it completes cleanly, I would consider #376 resolved.

Thank you again for taking the report seriously and using it to improve the connector more broadly.