Skip to content

revert: process tool folder resolution fallback (#1038) - #1047

Merged
robert-ursu merged 1 commit into
mainfrom
revert-1038-process-tool-folder-fallback
Aug 25, 2026
Merged

revert: process tool folder resolution fallback (#1038)#1047
robert-ursu merged 1 commit into
mainfrom
revert-1038-process-tool-folder-fallback

Conversation

@robert-ursu

Copy link
Copy Markdown
Contributor

Reverts the folder resolution change from #1038 (a1bd280). Version bumped 0.16.6 → 0.16.7.

Why

#1038 broke tool resolution for lowcode agents on serverless. The alpha CI agent (SimpleAgent on the PythonAwsTests / PythonK8sTests tenants) fails on every run with:

Failed to execute tool 'SumAgent'
Could not find folder for tool 'SumAgent'. Please check if the folder exists and is accessible by the robot.

Serverless.RuntimeVersions pins it to the package version, not to anything on the agent side — the agent itself hasn't changed:

Date (UTC) uipath-agents uipath-langchain SimpleAgent
08-11 → 08-13 200.0.5 → 200.0.12 0.16.2 / 0.16.3
08-18 / 08-21 200.0.0 / 200.1.0 0.15.2
08-15 / 08-20 200.0.13 0.16.5
08-21 201.0.0 0.16.5
08-25 201.0.4 0.16.6

Fails iff uipath-langchain >= 0.16.5 — the version #1038 shipped in.

Root cause

The change introduced this precedence in create_process_tool:

folder_path = get_execution_folder_path() or resource.properties.folder_path
folder_key = get_execution_folder_key() if not folder_path else None

On a serverless job UIPATH_FOLDER_PATH is unset, so it falls through to resource.properties.folder_path. For anything exported from Agent Builder / Solutions that value is the literal "solution_folder" placeholder baked into agent.json at export time. It's truthy, so:

  • folder_key is forced to None and the UIPATH_FOLDER_KEY fallback the PR was written for never fires — it's dead code for every packaged agent
  • StartJobs goes out with folderPath="solution_folder", Orchestrator rejects it (code 1100), and it surfaces as the "Could not find folder" message above

Before the change, folder_path=None was passed and the SDK resolved the process in the job's own execution folder — the correct behaviour for these agents. Lowcode agents never carry a usable folderPath; the real value arrives via binding overwrites at runtime.

The eval-serverless failure #1038 was chasing is a missing binding overwrite / fpsProperties advertisement on the eval path, not something to compensate for in the runtime.

Follow-up (agreed in this thread, separate PRs)

  • uipath-langchain: send resource.properties.folder_path literally, so coded agents can pass a folder explicitly
  • uipath-agents: force the folder in the agent definition to None, since lowcode agents always carry the solution_folder placeholder and rely on binding overwrites for the real value
  • fix: never send the solution_folder sentinel as a folder path #1044 addresses the same symptom by special-casing the solution_folder sentinel — a band-aid on top of this regression; superseded by the above

Reverting now to unblock the pipeline; the proper fix lands on its own timeline.

Testing

🤖 Generated with Claude Code

This reverts the folder resolution change from #1038 (a1bd280).

The new precedence — env path, then the resource's design-time folderPath,
then the folder key — makes the packaged folderPath shadow the live
execution context. Lowcode agents exported from Agent Builder/Solutions
always carry the literal "solution_folder" placeholder in agent.json, so on
serverless (where UIPATH_FOLDER_PATH is unset) StartJobs was called with
folderPath="solution_folder" and Orchestrator rejected it, surfacing as
"Could not find folder for tool '<tool>'". The UIPATH_FOLDER_KEY fallback
the change was added for never fired.

Restoring the previous behaviour passes folder_path=None so the SDK resolves
the tool in the job's own execution folder.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copilot AI lite review requested due to automatic review settings August 25, 2026 14:26

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR reverts the process-tool folder resolution fallback introduced in #1038, restoring the prior serverless behavior where process tools resolve within the execution context rather than using design-time folderPath. It also bumps the package version from 0.16.6 to 0.16.7 to ship the revert.

Changes:

  • Revert create_process_tool folder resolution to only use UIPATH_FOLDER_PATH, removing UIPATH_FOLDER_KEY/resource-folder fallbacks and related span metadata.
  • Remove the folder-resolution test suite added in #1038 and update remaining assertions to match the reverted invoke_async call signature.
  • Bump version to 0.16.7 and refresh uv.lock accordingly.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated no comments.

Show a summary per file
File Description
src/uipath_langchain/agent/tools/process_tool.py Reverts folder resolution logic to only use get_execution_folder_path() and removes folder_key usage/metadata.
src/uipath_langchain/_utils/_environment.py Removes get_execution_folder_key() helper, leaving only folder path env lookup.
src/uipath_langchain/_utils/__init__.py Stops exporting get_execution_folder_key from _utils.
tests/agent/tools/test_process_tool.py Deletes folder fallback tests and updates call assertions to omit folder_key=None.
pyproject.toml Version bump 0.16.60.16.7.
uv.lock Lockfile updated for the version bump and refreshed resolution metadata/markers.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@sonarqubecloud

Copy link
Copy Markdown

@robert-ursu
robert-ursu merged commit 191bb45 into main Aug 25, 2026
73 of 74 checks passed
@robert-ursu
robert-ursu deleted the revert-1038-process-tool-folder-fallback branch August 25, 2026 15:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants