fix(delete_project_file): use URL segment for path + refuse root deletes (prevents whole-project wipe)

[arsyakaukabi]

Summary

Fixes the destructive bug reported in #13. delete_project_file was sending the target path as a ?path= query string, which the Cloudera AI Workbench v2 Files API silently ignores. The actual request was:

DELETE /api/v2/projects/{project_id}/files

i.e. delete the entire project file tree, recursively, regardless of which file_path the caller specified. The tool then reported success: true because the server returned 200.

This has caused at least one real incident in production use (full project wipe via the MCP tool, recovered only via platform backup). Filing the fix as soon as the incident was contained.

Changes

1. Send the path as a URL segment, matching the working download_project_file_v2 / patched list_project_files endpoints:

   delete_url = f"{host}/api/v2/projects/{project_id}/files/{encoded_file_path}"

2. Refuse file_path values that normalize to the project root ("", "/", ".", ".."). Even with the URL fix in place, this tool should never target the project file root — adding the guard means a future regression in URL handling cannot reintroduce the catastrophic outcome.

Test plan

• Manually confirmed the new URL shape against the Cloudera v2 API on livyatan.apps.slithereen.data.bri.co.id: deleting PLAYGROUND/<user>/scratch.txt now deletes only that file and leaves siblings intact.
• Manually confirmed the guard: calls with file_path="", "/", ".", or ".." are now rejected before any HTTP request is sent.
• Manually confirmed nested-path deletes still work end-to-end (a/b/c/file.txt).

Related

• Closes delete_project_file_tool sends path as ?path= query (silently ignored) — server interprets DELETE as 'delete project file root', causing total project data loss #13
• Sibling (non-destructive) bug: list_project_files_tool: path argument is silently ignored, always returns project root #10 / PR fix: send list_project_files path as URL segment so subdirectories actually work #12 — same ?path= pattern in list_project_files.

[Khauneesh-AI]

Hi @arsyakaukabi — thank you for catching this and putting together the fix. The underlying issue (path
encoding + root delete guard) has been resolved in v2.0.0 via a complete migration to the official
cmlapi Python SDK, which handles URL construction and path encoding correctly.

The relevant fix landed in commit 56ee14d (DSE-54632) and was further solidified in b591376 where all
tools now use client.delete_project_file(project_id, path) — the SDK builds the correct URL
internally.

Closing this PR since the fix is now on main, but your bug report and repro were invaluable in
prioritizing this. For future contributions, please target the dev branch — see our contributing
workflow.

Thanks again! 🙏