Repository navigation
fix(cli): raise on 404 from Studio Web project Structure - #1926
Conversation
github-actions
Bot
added
test:uipath-langchain
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The focused error-handling correction is consistent across both affected layers and has appropriate regression coverage.
Review effort: Balanced
Findings: None
What changed in this PR
Prevents Studio Web Structure 404 responses from being mistaken for empty projects, ensuring invalid push targets fail safely.
Changes:
- Propagates Structure API errors instead of synthesizing empty structures.
- Removes the upload-layer 404 fallback and adds regression coverage.
- Bumps
uipathto 2.14.33.
| File | Description |
|---|---|
packages/uipath/src/uipath/_cli/_utils/_studio_project.py |
Propagates Structure request failures. |
packages/uipath/src/uipath/_cli/_push/sw_file_handler.py |
Removes duplicate 404 recovery logic. |
packages/uipath/tests/cli/test_push.py |
Verifies 404 blocks uploads. |
packages/uipath/pyproject.toml |
Bumps package version. |
packages/uipath/uv.lock |
Updates the locked project version. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
9b40ecb to
8fbbb58
Compare
8fbbb58 to
c2d15a9
Compare
🚨 Heads up:
|
get_project_structure_async turned any 404 from FileOperations/Structure into an empty ProjectStructure, so a failed fetch was indistinguishable from a fresh project and the push gate allowed the push. Studio Web now creates project.uiproj with every new project, so a 404 only means the project id or the base URL is wrong (e.g. UIPATH_URL without the organization segment). Propagate the error, carrying the request URL and status, and drop the matching 404 fallback in the push file handler. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
c2d15a9 to
ceca58e
Compare
🚨 Heads up:
|
|
Problem
StudioClient.get_project_structure_async()returned an emptyProjectStructurewhenGET /studio_/backend/api/Project/{id}/FileOperations/Structureanswered 404, instead of raising.ensure_coded_project_asynctreats an empty structure as a never-pushed project, so a failed fetch granted permission to push.This bites with
UIPATH_URL=https://cloud.uipath.com(bare host, no org segment): the cloud gateway returns 404 for the org-less/studio_/...path even with a valid token, the 404 was swallowed, and the push proceeded while the siblingLockcall failed with the real error.Reproduced on
uipath2.14.32 against a freshly created cloud Function project:UIPATH_URLStructureget_project_structure_asynchttps://cloud.uipath.com/<org>/<tenant>['project.uiproj']https://cloud.uipath.comThe 404 handling was added in #1820 for Function projects whose file system was never initialized. That premise no longer holds: Studio Web now writes
project.uiprojas a tracked resource with every project create, so a fresh Function project returns 200 withproject.uiprojat the root (confirmed on both alpha and cloud). #1870 already admits such projects via the project-type fallback.Fix
StudioClient.get_project_structure_async: no longer catches 404. Any non-2xx propagates asEnrichedException, whose message carries the request URL, method, status and response body.SwFileHandler.upload_source_files: removed the older matching 404 fallback that created an empty structure and took a lock, so the error cannot be swallowed one layer up either. Docstring updated accordingly.ensure_coded_project_asyncis unchanged; it can now only be reached by a genuine 200 with no files.With the fix, the same cloud project: bare host →
EnrichedException404 with the Structure URL, push blocked; scoped URL →['project.uiproj'], push allowed.Tests
test_first_push_to_uninitialized_projectwithtest_push_fails_when_structure_returns_404: exit code 1,EnrichedExceptionwith status 404 and the Structure URL, nothing uploaded.tests/cli/test_push.py: 35 passed; ruff + mypy clean.Version
uipath2.14.38 → 2.14.39🤖 Generated with Claude Code