fix(healing): replace VAR markers in place and handle agent task steps

[RaphaelFakhri]

Summary

VariableExtractor.process_workflow_with_markers replaced the entire field value with the {variable} reference of the last marker it found. Three cases produced wrong workflows:

• A marker inside a longer string, such as the documented navigation example https://example.com/search?q=VAR:search_term:laptop, became {search_term} and dropped the URL.
• Two markers in one field, such as VAR:first_name:John VAR:last_name:Doe, became only {last_name}.
• A marker in an agent step task, documented in print_variable_marker_help, was never processed because task was not in the list of checked fields.

The method now replaces each marker where it appears and keeps the surrounding text. A field that consists of a single marker still becomes one {variable} reference, so a value with spaces such as VAR:country:United States behaves as before. Agent steps now check task.

Tests

test_variable_extractor.py could not run on main: five tests built a WorkflowDefinitionSchema without the final extract step that the schema validator requires. The change adds the extract step to those fixtures and adds tests for multiple markers in one field and for markers in an agent task.

cd workflows && uv run pytest workflow_use/healing/tests/test_variable_extractor.py

• Before the fix (tests updated, source reverted): 3 failed, 8 passed (test_marker_in_navigation_url, test_multiple_markers_in_one_field, test_marker_in_agent_task).
• After the fix: 11 passed.
• ruff check and ruff format --check pass on workflow_use/healing.

---

Summary by cubic

Fixes variable marker replacement so markers are replaced in place instead of wiping out the surrounding field value.

Previously, a marker inside a string like https://example.com/search?q=VAR:search_term:laptop became just {search_term}, dropping the URL, and a field with multiple markers kept only the last one. Agent step task fields were never processed at all. Markers now keep surrounding text, single-marker values with spaces still become one {variable} reference, and agent tasks are covered.

• Added test fixtures for agent task markers and multiple markers in one field.
• Fixed five existing tests that couldn't run because they were missing the required extract step.

^{Written for commit fe07e5a. Summary will update on new commits.}

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cubic-dev-ai]

1 issue found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="workflows/workflow_use/healing/variable_extractor.py">

<violation number="1" location="workflows/workflow_use/healing/variable_extractor.py:218">
P2: Multi-word marker values are only preserved by the new `WHOLE_FIELD_MARKER_PATTERN` branch when the marker is the entire field. When the same marker (e.g. `VAR:country:United States`) is embedded in surrounding text, `MANUAL_MARKER_PATTERN.sub` truncates the value at the first space and silently leaks the remainder: `'Go to VAR:city:New York office'` becomes `'Go to {city} York office'`, and `'VAR:first_name:John Doe VAR:last_name:Doe'` becomes `'{first_name} Doe {last_name}'`. This is most likely to surface in the newly supported agent `task` and `description` fields, which are free-form natural language. Align the inline replacement with the whole-field rule (capture the value up to the next `VAR:` token or end of string, tolerating spaces), or keep values single-token and reject spaces explicitly instead of silently corrupting the field.</violation>
</file>

<sub>Heads up: you’ve reached your flex budget. Increase your flex budget or wait for usage to reset.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: Multi-word marker values are only preserved by the new WHOLE_FIELD_MARKER_PATTERN branch when the marker is the entire field. When the same marker (e.g. VAR:country:United States) is embedded in surrounding text, MANUAL_MARKER_PATTERN.sub truncates the value at the first space and silently leaks the remainder: 'Go to VAR:city:New York office' becomes 'Go to {city} York office', and 'VAR:first_name:John Doe VAR:last_name:Doe' becomes '{first_name} Doe {last_name}'. This is most likely to surface in the newly supported agent task and description fields, which are free-form natural language. Align the inline replacement with the whole-field rule (capture the value up to the next VAR: token or end of string, tolerating spaces), or keep values single-token and reject spaces explicitly instead of silently corrupting the field.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At workflows/workflow_use/healing/variable_extractor.py, line 218:

<comment>Multi-word marker values are only preserved by the new `WHOLE_FIELD_MARKER_PATTERN` branch when the marker is the entire field. When the same marker (e.g. `VAR:country:United States`) is embedded in surrounding text, `MANUAL_MARKER_PATTERN.sub` truncates the value at the first space and silently leaks the remainder: `'Go to VAR:city:New York office'` becomes `'Go to {city} York office'`, and `'VAR:first_name:John Doe VAR:last_name:Doe'` becomes `'{first_name} Doe {last_name}'`. This is most likely to surface in the newly supported agent `task` and `description` fields, which are free-form natural language. Align the inline replacement with the whole-field rule (capture the value up to the next `VAR:` token or end of string, tolerating spaces), or keep values single-token and reject spaces explicitly instead of silently corrupting the field.</comment>

<file context>
@@ -203,8 +209,13 @@ def _process_step_markers(self, step: WorkflowStep, extracted_inputs: Dict[str,
+				updated_value = f'{{{whole_field.group(1)}}}'
+			else:
+				# Replace each marker where it appears and keep the surrounding text
+				updated_value = self.MANUAL_MARKER_PATTERN.sub(lambda m: f'{{{m.group(1)}}}', field_value)
 
 			# Update the field
</file context>

[RaphaelFakhri]

MANUAL_MARKER_PATTERN documents that an inline value ends at the first whitespace, and this change keeps that grammar. Inside free text there is no way to tell where a multi-word value ends, so capturing up to the next VAR: would swallow the rest of the sentence, for example Go to VAR:city:Paris and book a hotel. Write a multi-word value as the whole field, which this change supports, or as a single token.