bug: update_subtask produces malformed XML with duplicated content

[cwardgar]

update_subtask has a bug where it:

1. Creates malformed XML structures with mismatched opening/closing tags
2. Nests duplicate content recursively instead of appending linearly
3. Creates both <update> and <info added on> tags for no apparent reason.

To reproduce, simply update the same subtask twice. I should note that I used the MCP server for the update operation, if that matters.

[cwardgar]

An example subtask:

        {
          "id": 1,
          "title": "Flask Installation and Configuration",
          "description": "Set up Flask framework with necessary dependencies and configure the basic application structure",
          "dependencies": [],
          "details": "Install Flask using pip, create the main app.py file with basic Flask configuration, set up Flask-Assets for static asset management, and configure the development environment variables\n<info added on 2025-05-14T02:51:37.205Z>\n<update timestamp=\"2025-05-14T02:51:32Z\">Flask installation has been planned and configured by adding `Flask>=3.0.0` to `project.dependencies` in `pyproject.toml`. The user is instructed to run `uv pip install -e .` to install Flask and its dependencies. The main application file `src/amazon_expenses_splitter/app.py` has been created with a basic 'Hello, World!' Flask application, including debug mode enabled for development. Flask's built-in static file handling will be used initially, with the option to revisit Flask-Assets integration if needed during Tailwind CSS setup. Environment variable configuration is currently handled via the debug flag in `app.run(debug=True)`, but `.flaskenv` can be considered for more granular environment management in the future. The project structure follows best practices, with a dedicated package directory and a virtual environment for dependency isolation. For further configuration, environment variables prefixed with `FLASK_` can be loaded into the Flask config using `from_prefixed_env()` for production or advanced setups.</update>\n</info added on 2025-05-14T02:51:37.205Z>\n<info added on 2025-05-14T03:25:12.902Z>\nFlask development server is running successfully and the 'Hello, World!' endpoint is accessible at http://127.0.0.1:5000/. Linter errors related to Flask imports in `app.py` have been resolved. The basic Flask installation and application structure are confirmed working. Flask-Assets integration is deferred for now; built-in static file handling will be used initially. The project structure follows best practices, with a dedicated package directory and a virtual environment for dependency isolation. Environment variables are managed via the debug flag in `app.run(debug=True)`, with the option to use `.flaskenv` for more granular environment management in the future. For production or advanced setups, environment variables prefixed with `FLASK_` can be loaded into the Flask config using `from_prefixed_env()`. The next step is to proceed with HTMX integration, which will involve adding the HTMX library to the static directory and configuring routes to return HTML snippets for dynamic content updates without full page reloads[5][1].\n<info added on 2025-05-14T02:51:37.205Z>\n<update timestamp=\"2025-05-14T02:51:32Z\">Flask installation has been planned and configured by adding `Flask>=3.0.0` to `project.dependencies` in `pyproject.toml`. The user is instructed to run `uv pip install -e .` to install Flask and its dependencies. The main application file `src/amazon_expenses_splitter/app.py` has been created with a basic 'Hello, World!' Flask application, including debug mode enabled for development. Flask's built-in static file handling will be used initially, with the option to revisit Flask-Assets integration if needed during Tailwind CSS setup. Environment variable configuration is currently handled via the debug flag in `app.run(debug=True)`, but `.flaskenv` can be considered for more granular environment management in the future. The project structure follows best practices, with a dedicated package directory and a virtual environment for dependency isolation. For further configuration, environment variables prefixed with `FLASK_` can be loaded into the Flask config using `from_prefixed_env()` for production or advanced setups.</update>\n<info added on 2025-05-14T03:25:03.000Z>\n<update timestamp=\"2025-05-14T03:25:03Z\">Verification complete: Flask development server runs successfully. 'Hello, World!' is accessible at http://127.0.0.1:5000/. Linter error for Flask import in `app.py` is resolved. Basic Flask installation and `app.py` setup are confirmed working. Flask-Assets setup deferred, will use built-in static handling for now. Ready to proceed with HTMX integration, which will involve downloading the HTMX library to the static directory and configuring Flask routes to return HTML snippets for dynamic content updates. This approach enables partial page reloads and interactive features without requiring full page refreshes, aligning with modern web development practices[5][1].</update>\n</info added on 2025-05-14T03:25:12.902Z>",
          "status": "done"
        }

[cwardgar]

I'm also seeing inconsistent usage of <update> tags. Sometimes there will be an open and close, e.g. <update timestamp="2025-05-10T03:17:51Z"> CONTENT </update>. Other times "update" will be a self-closing tag, e.g. <update timestamp="2025-05-10T03:17:51Z" />.

Also, sometimes "update" will be paired with "info added on", sometimes it won't. Shouldn't we just use "update" for this? <info added on ...> isn't a valid XML tag, even if an LLM understands it.

[eyaltoledano]

I'm also seeing inconsistent usage of <update> tags. Sometimes there will be an open and close, e.g. <update timestamp="2025-05-10T03:17:51Z"> CONTENT </update>. Other times "update" will be a self-closing tag, e.g. <update timestamp="2025-05-10T03:17:51Z" />.

Also, sometimes "update" will be paired with "info added on", sometimes it won't. Shouldn't we just use "update" for this? <info added on ...> isn't a valid XML tag, even if an LLM understands it.

thanks for reporting this -- I'm going to take a look next I sit down

It's my release week for 0.17, I'll see what's up

[Crunchyman-ralph]

@cwardgar which model are you using for this ?

[cwardgar]

@Crunchyman-ralph I'm using Sonnet 4 now, but I note this behavior in older tasks. I may have been on Sonnet 3.7 or possibly even Gemini 2.5 back then.

Yesterday I updated a subtask twice and did not observe the behavior I noted in the OP. Maybe this issue only affects older versions? But even if that's true, bugs of yesterday remain with us in the form of malformed older tasks.

[Crunchyman-ralph]

Alright, lets close this for now and re-open or create a new issue if the issue persists. Lets assume this is resolved as of 0.19.0