fix(platform)!: drop inert OData params from list_records

[avichalsri24]

Problem

EntitiesService.list_records advertises OData filtering:

filter (Optional[str]): OData $filter expression (e.g. "status eq 'active'")

The endpoint it calls — GET datafabric_/api/EntityService/entity/{key}/read — does not implement it. It accepts $filter, $orderby, $select and $expand, ignores them, and returns the full unfiltered set. The failure mode is a silent wrong answer: a filtered query returns every record, with no error.

Verified against a live tenant (TestEntity, 32 records), via the SDK and raw httpx:

Request	Result
no params	32 records
$filter=Name eq '<one real match>'	32 records
$filter=Name eq 'definitely-no-such-value-xyz'	32 records
$filter=bogus syntax (((	HTTP 200, 32 records
$select=Name	32 records, all 7 columns
$orderby=Name desc	order unchanged
filter=… (no $) / query=…	32 records

What the endpoint does honour:

Param	Honoured	Evidence
start	yes	start=30 → 2 of 32; start=100 → 0
limit	yes	1/2/31 → exact; 1000 → 32; 0 → 32 (treated as unset); -1 → HTTP 400 Invalid limit -1
expansionLevel	yes	0 → bare guid, 1 → {Id}, 2 → full nested record

GET api/v2/.../read returns 404, so there is no newer read endpoint these params were written against.

Why CI didn't catch it

The four params were added in #1616 alongside the (working) structured query API. The covering test asserted only that pytest-httpx received them:

assert params.get("$filter") == "status eq 'active'"
assert params.get("$orderby") == "name asc"

That passes whether or not the server implements any of it — the mock replies with whatever the test told it to.

Change

Remove filter, orderby, select and expand from list_records / list_records_async and from _list_records_spec. This restores the pre-#1616 parameter surface (entity_key, schema, start, limit) plus expansion_level, which does work — nothing that ever functioned is lost.

Filtering, sorting and projection already have a working home in retrieve_records (POST .../query, EntityQueryFilterGroup); docstrings and examples now point there. _list_records_spec records why the params are not sent, so they don't get re-added.

The test now asserts the positive contract and the negative one:

assert params.get("start") == "0"
assert params.get("limit") == "3"
assert params.get("expansionLevel") == "2"
assert [key for key in params if key.startswith("$")] == []

Note for reviewers: filtering a related entity's field via retrieve_records needs field_name="Rel.Id" and expansion_level>=1, otherwise the backend rejects it with "Filtering or sorting fields from related entities has to be expanded in the query". Filtering on the bare relationship name (CreatedBy eq '<guid>') is silently ignored — same class of trap, on the endpoint that otherwise works.

Verification

Live tenant, with this branch's source:

limit=2, expansion_level=2 -> returned=2 total=32
  CreatedBy expanded to: <full nested SystemUser record>
start=30                   -> returned=2 total=32
filter=…                   -> TypeError: got an unexpected keyword argument 'filter'

uipath-platform suite passes, ruff check / ruff format --check clean, mypy src clean (163 files).

Breaking change

list_records() / list_records_async() no longer accept filter, orderby, select or expand. Passing them raises TypeError instead of silently returning unfiltered records. Callers migrate to retrieve_records() with an EntityQueryFilterGroup.

Happy to swap this for a deprecation window (keep the params, raise NotImplementedError) if reviewers prefer a softer landing.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR removes OData-related parameters from EntitiesService.list_records / list_records_async in uipath-platform because the underlying Data Fabric /read endpoint accepts those params but silently ignores them, creating a “silent wrong answer” failure mode. The change narrows the public API to the parameters the endpoint actually honors (paging + expansion), updates documentation/examples to route filtering/sorting/projection to the structured query API, and adjusts tests accordingly.

Changes:

• Drop inert filter, orderby, select, expand kwargs from sync/async list_records and from the internal request spec builder.
• Update docs/examples to point filtering/sorting/projection to retrieve_records (POST .../query) instead of list_records.
• Update unit test assertions to ensure only paging/expansion params are sent; bump uipath-platform version.

File summaries

File	Description
packages/uipath-platform/src/uipath/platform/entities/_entity_data_service.py	Removes OData kwargs from internal list methods/spec; documents why OData params are not sent.
packages/uipath-platform/src/uipath/platform/entities/_entities_service.py	Removes OData kwargs from the public facade; updates docstrings/examples to use retrieve_records.
packages/uipath-platform/tests/services/test_entities_service.py	Updates the list-records test to assert only paging/expansion params are sent.
packages/uipath-platform/pyproject.toml	Bumps the uipath-platform package version.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Lite

---

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

[Copilot]

🟢 Approval recommended

Review details

• Files reviewed: 4/6 changed files
• Comments generated: 0 new
• Review effort level: Lite

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🚨 Heads up: uipath-langchain cross-tests are FAILING 🚨

Your changes may break the uipath-langchain-python integration.

⚠️ These checks are NOT enforced by branch protection rules. Please review the failures before merging.

🔍 Inspect the failed run →