Invalid operations xml format

[d-oit]

App Version

3.16.3

API Provider

Google Gemini or https://integrate.api.nvidia.com/v1

Model Used

gemini-2.5-pro-exp-03-25 / nvidia/llama-3.1-nemotron-ultra-253b-v1 - model independepent

Actual vs. Expected Behavior

see log

adjust xml parser or system prompt:
handle characters like <, >, and & in element text should be escaped.

Detailed Steps to Reproduce

Ask mode user prompt

create a question to get this answer with ask_followup_question and follow_up

Should we define any specific performance budgets (e.g., TTI < 5s on slow 3G, FCP < 2s, max JS bundle size < 200KB)?

Yes, TTI < 5s on simulated slow 3G, FCP < 2s.
Let's aim for Lighthouse scores above 90 for performance.
No specific budgets for now, but we should prioritize good performance generally.
Use best practice (e.g., Aim for Lighthouse performance score > 90. Target FCP < 1.8s, LCP < 2.5s, TTI < 5s on a representative mobile device/network. Keep main thread JS bundle (post-compression) < 150-200KB. These are good starting points to ensure a snappy experience).

Relevant API Request Output or Error Logs

**Assistant:**

Understood. We will proceed with the pragmatic approach of **relying on the device's underlying OS-level encryption** for data at rest in IndexedDB. We will not implement application-level encryption for specific fields at this stage, but we'll keep this as a potential future enhancement if specific highly sensitive data categories emerge.

Now, let's shift focus to **Performance, Logging & Error Handling**.

First, **Performance Budgets**. Do we want to set any specific performance targets? For example, Time to Interactive (TTI), First Contentful Paint (FCP), or bundle size limits. This helps keep performance in check during development.

<ask_followup_question>
<question>Should we define any specific performance budgets (e.g., TTI < 5s on slow 3G, FCP < 2s, max JS bundle size < 200KB)?</question>
<follow_up>
<suggest>Yes, TTI < 5s on simulated slow 3G, FCP < 2s.</suggest>
<suggest>Let's aim for Lighthouse scores above 90 for performance.</suggest>
<suggest>No specific budgets for now, but we should prioritize good performance generally.</suggest>
<suggest>Use best practice (e.g., Aim for Lighthouse performance score > 90. Target FCP < 1.8s, LCP < 2.5s, TTI < 5s on a representative mobile device/network. Keep main thread JS bundle (post-compression) < 150-200KB. These are good starting points to ensure a snappy experience).</suggest>
</follow_up>
</ask_followup_question>

---

**User:**

[ask_followup_question for 'Should we define any specific performance budgets (e.g., TTI < 5s on slow 3G, FCP < 2s, max JS bundle size < 200KB)?'] Result:
The tool execution failed with the following error:
<error>
Invalid operations xml format
</error>
<environment_details>
# VSCode Visible Files


# VSCode Open Tabs
guide.md


# Current Context Size (Tokens)
21,775 (2%)

# Current Cost
$0.00

# Current Mode
<slug>architect</slug>
<name>🏗️ Architect</name>
<model>gemini-2.5-pro-exp-03-25</model>
</environment_details>

Additional Context

Comprehensive Update Comment for Issue #3404

Status Update: Issue confirmed and root cause identified. The XML parser in askFollowupQuestionTool.ts fails when processing <suggest> elements containing unescaped special characters (<, >, &).

Root Cause Analysis:
The issue occurs when performance-related content like "TTI < 5s" is included in suggestion text. The fast-xml-parser library fails because these characters break XML structure unless properly escaped or the parser is configured to handle entities.

All Possible Fix Solutions:

Option 1: Enable Entity Processing in Parser (Recommended)

Update parseXml() in src/utils/xml.ts:

const parser = new XMLParser({
    ignoreAttributes: false,
    attributeNamePrefix: "@_",
    parseAttributeValue: false,
    parseTagValue: false,
    trimValues: true,
    stopNodes: _stopNodes,
    processEntities: true,    // Handle <, >, &
    htmlEntities: true,      // Handle HTML entities
    allowBooleanAttributes: true
})

Option 2: Pre-process XML Content with Escaping

Add escaping function before parsing in askFollowupQuestionTool.ts:

function escapeXmlContent(xmlString: string): string {
    return xmlString.replace(/(<[^>]+>)([^<]*)/g, (match, tag, content) => {
        const escapedContent = content
            .replace(/&/g, '&amp;')
            .replace(/</g, '&lt;')
            .replace(/>/g, '&gt;')
        return tag + escapedContent
    })
}

// Before parsing:
const escapedFollowUp = escapeXmlContent(follow_up)
parsedSuggest = parseXml(escapedFollowUp, ["suggest"])

Option 3: Use CDATA Sections

Modify the system prompt to wrap problematic content in CDATA:

<suggest><![CDATA[TTI < 5s on slow 3G, FCP < 2s]]></suggest>

Enable CDATA handling in parser:

const parser = new XMLParser({
    ...existingOptions,
    cdataPropName: "__cdata"
})

Option 4: Alternative XML Structure

Change the XML structure to use attributes instead of text content:

<suggest text="TTI &lt; 5s on slow 3G, FCP &lt; 2s" />

Option 5: Enhanced Error Handling with Fallback

Add try-catch with automatic escaping fallback in askFollowupQuestionTool.ts:

try {
    parsedSuggest = parseXml(follow_up, ["suggest"])
} catch (error) {
    // Fallback: try with escaped content
    const escapedFollowUp = follow_up
        .replace(/&/g, '&')
        .replace(/</g, '&lt;')
        .replace(/>/g, '&gt;')
    try {
        parsedSuggest = parseXml(escapedFollowUp, ["suggest"])
    } catch (fallbackError) {
        // Original error handling
        cline.consecutiveMistakeCount++
        cline.recordToolError("ask_followup_question")
        await cline.say("error", `Failed to parse operations: ${error.message}`)
        pushToolResult(formatResponse.toolError("Invalid operations xml format"))
        return
    }
}

Option 6: Update System Prompt

Modify the system prompt to instruct the AI to escape special characters:

When using ask_followup_question, ensure that suggestion content escapes XML special characters:
- Replace < with &lt;
- Replace > with &gt;  
- Replace & with &amp;

Option 7: JSON-based Alternative

Replace XML parsing with JSON for follow_up suggestions:

// Instead of XML parsing, use JSON structure
const followUpJson = {
    suggestions: [
        "TTI < 5s on slow 3G, FCP < 2s",
        "Lighthouse scores above 90"
    ]
}

Test Prompt to Verify the Issue:

Use the following prompt in Ask mode:

Should we define any specific performance budgets (e.g., TTI < 5s on slow 3G, FCP < 2s, max JS bundle size < 200KB)?

<ask_followup_question>
<question>Should we define any specific performance budgets (e.g., TTI < 5s on slow 3G, FCP < 2s, max JS bundle size < 200KB)?</question>
<follow_up>
<suggest>Yes, TTI < 5s on simulated slow 3G, FCP < 2s.</suggest>
<suggest>Let's aim for Lighthouse scores above 90 for performance.</suggest>
<suggest>Use best practice (e.g., Aim for Lighthouse performance score > 90. Target FCP < 1.8s, LCP < 2.5s, TTI < 5s on a representative mobile device/network. Keep main thread JS bundle (post-compression) < 150-200KB.</suggest>
</follow_up>
</ask_followup_question>

or in Ask mode with the open RooCode repo:

**read @https://github.com/RooCodeInc/Roo-Code/issues/3404**

Expected Result: Should fail with "Invalid operations xml format" error
After Fix: Should parse successfully and display the follow-up suggestions

Recommendation: Start with Option 1 (enable entity processing) as it's the least invasive and most robust solution. If that doesn't work, implement Option 5 (enhanced error handling with fallback) for maximum compatibility.

[hannesrudolph]

OK so I have clarified what this you were saying @d-oit

They’re saying the XML parser (or prompt output format) chokes on characters like <, >, and & when they’re used inside the ask_followup_question block. Their example shows a prompt that includes valid HTML/XML-looking content, and the assistant tries to echo it back verbatim, but that leads to an invalid XML structure—causing a tool failure.

Their point: either the parser should escape those characters, or the system prompt should warn the model not to output raw <, > in XML-style blocks unless escaped.

@d-oit Could you please provide some clear and easy to follow repro steps so the dev or contributor taking this on can easily verify the fix?