Editing a task while it runs

You can edit and save a task while one of its executions is running. The edit does not reach the run in progress: it waits for the task's next execution. This page says what the running execution keeps, when the edit takes effect, and what happens to an edit HarmFlow cannot accept.

What the running execution keeps

An execution runs the task as it was when the execution started, from its first step to its last. Saving an edit meanwhile changes none of these for it:

• Its prompt. The harness keeps working on the prompt it started with, and so does a fallback harness the execution switches to later.
• Its failover settings. The fallback harnesses it may switch to, even when the edit adds or removes one.
• Its notification settings. The events it notifies you about.
• Its timeout. Lengthening or shortening the timeout does not move the end of the run in progress.
• Its rate-limit retries. How many times it waits and tries again after a rate limit.
• Its harness switches. How many times it may turn to a fallback harness.

When the edit takes effect

The edit applies from the task's next execution, which starts with the edited values: the new prompt, the new timeout, the new fallback harnesses. A firing that is still waiting to start when you save, behind the execution that runs, is a next execution too, and it starts with the edit.

An edit that is not valid

HarmFlow checks an edit before it saves it. An edit that fails that check is refused, and HarmFlow names what is wrong with it. A refused edit changes nothing:

• the running execution goes on with the values it started with;
• the saved task stays as it was, so its next execution runs the last valid version, not part of the refused one.

Correct the edit and save it again: once it is saved, it applies from the next execution.