Skip to content

Data Fabric native integration with Agents - Coded and Non-Coded [DS-7139]#1331

Open
UIPath-Harshit wants to merge 7 commits intomainfrom
feat/df-agent-integrations
Open

Data Fabric native integration with Agents - Coded and Non-Coded [DS-7139]#1331
UIPath-Harshit wants to merge 7 commits intomainfrom
feat/df-agent-integrations

Conversation

@UIPath-Harshit
Copy link

This pull request introduces support for Data Fabric context and secure SQL-based querying of multiple entities in UiPath Data Service. It adds new APIs for querying with SQL, enforces strict validation rules to prevent unsafe queries, and extends the agent model and configuration to support the new Data Fabric retrieval mode. Comprehensive tests are included to ensure correct behavior and validation.

Data Fabric context support and agent model updates:

  • Added DATA_FABRIC as a new retrieval mode in AgentContextRetrievalMode and updated related model classes and normalization logic to support it, including new entity_identifiers settings. [1] [2] [3] [4]
  • Added tests to verify that DATA_FABRIC retrieval mode and its configuration are parsed and validated correctly.

SQL query support for entities (Data Fabric):

  • Introduced new methods query_multiple_entities and query_multiple_entities_async to EntitiesService, allowing SQL-based queries against entity data via the Data Fabric endpoint.
  • Implemented _query_multiple_entities_spec to construct the request for the new Data Fabric query API.

SQL query validation and security:

  • Implemented _validate_sql_query and helper methods to strictly validate SQL queries: only single SELECT statements are allowed, forbids dangerous keywords and constructs (e.g., INSERT, UPDATE, UNION, subqueries), and enforces WHERE or LIMIT clauses and projection limits to prevent unbounded or unsafe queries.
  • Added comprehensive tests for SQL query validation, including both allowed and disallowed queries, and ensured that invalid queries are rejected before any network call is made.

Dependency and configuration updates:

  • Added sqlparse as a required dependency for SQL parsing and validation, and updated development dependencies and workspace configuration for uipath. [1] [2] [3]

Documentation improvements:

  • Updated class and method docstrings to clarify the experimental nature of Data Fabric SQL query APIs and their intended usage.

@github-actions github-actions bot added test:uipath-langchain Triggers tests in the uipath-langchain-python repository test:uipath-llamaindex Triggers tests in the uipath-llamaindex-python repository labels Feb 17, 2026
Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5bc48d5d0a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +469 to +470
records_data = response.json().get("results", [])
return records_data

Choose a reason for hiding this comment

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

P2 Badge Honor schema argument in entity query methods

The new query_multiple_entities API accepts schema and documents it as validation input, but the method returns raw response.json()["results"] without ever applying that schema (and the async variant has the same behavior). In callers that rely on schema validation, malformed or shape-shifted records will pass through silently and fail later in downstream logic instead of failing at the SDK boundary.

Useful? React with 👍 / 👎.

Comment on lines +468 to +472
if response.status_code == 200:
records_data = response.json().get("results", [])
return records_data
else:
response.raise_for_status()

Choose a reason for hiding this comment

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

P2 Badge Handle non-200 successful responses consistently

This branch treats only 200 as success even though BaseService.request already raises for error statuses; for any other successful 2xx response (for example 204), execution falls into else, raise_for_status() is a no-op, and the method returns None despite its declared List[Dict[str, Any]] return type. That creates a latent runtime type break if the endpoint ever returns a non-200 success code.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

test:uipath-langchain Triggers tests in the uipath-langchain-python repository test:uipath-llamaindex Triggers tests in the uipath-llamaindex-python repository

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant