Skip to content

files, collections: reject unknown order, sort_by and metric values - #233

Open
deanrie wants to merge 1 commit into
xai-org:mainfrom
deanrie:reject-unknown-sort-order
Open

deanrie wants to merge 1 commit into
xai-org:mainfrom
deanrie:reject-unknown-sort-order

Conversation

@deanrie

@deanrie deanrie commented Oct 22, 2026

Copy link
Copy Markdown

Checklist

  • I have read both the CONTRIBUTING.md and Contributor License Agreement documents.
  • I have created an issue or feature request and received approval from xAI maintainers. (consistency fix found by reading the helpers; no issue filed)
  • I have tested my changes locally and they pass all CI checks.
  • I have added necessary documentation or updated existing documentation. (CHANGELOG)

Description

The listing helpers in files.py and collections.py convert the order, sort_by, and metric_space literals to protobuf enums with a match whose case _ returns a default (or the UNKNOWN enum value):

def _order_to_pb(order: Order | None) -> files_pb2.Ordering:
    match order:
        case "asc": ...
        case "desc": ...
        case _: return files_pb2.Ordering.ASCENDING

So at runtime client.files.list(order="dsc") lists ascending, sort_by="created" sorts by the default column, and collections.create(metric_space="cos") creates a collection with HNSW_METRIC_UNKNOWN, all without a word. Type checkers catch these for literal arguments, but values that come from config, CLI flags, or user input reach the SDK as plain str.

Every other literal parameter in the SDK already raises: reasoning_effort (chat.py), service_tier, search mode, image format / quality / aspect_ratio / resolution, field definition op. This change brings the five sort/order/metric helpers in line: an unknown non-None value raises ValueError naming the accepted values; None keeps its current meaning (the default, or ORDERING_UNKNOWN for collections, which lets the server choose).

Tests

  • tests/sync/files_test.py: "dsc" and "created" raise with the expected messages; existing None assertions unchanged.
  • tests/sync/collections_test.py: "dsc", "names", "created", "cos" raise; None still maps to the previous defaults.

Both new tests fail on main. uv run pytest on the four files/collections test modules: 251 passed. ruff check, ruff format --check, pyright clean on the touched files.

@deanrie
deanrie requested a review from a team as a code owner October 22, 2026 17:18
_order_to_pb, _sort_by_to_pb, _collection_sort_by_to_pb,
_document_sort_by_to_pb and _hnsw_metric_to_pb matched the known
literals and returned a default (or the UNKNOWN enum) for anything else,
so order="dsc" listed ascending, sort_by="created" sorted by the
default column, and metric_space="cos" created a collection with an
unknown metric, all without a word. Every other literal parameter in the
SDK raises ValueError with the accepted values (reasoning_effort,
service_tier, search mode, image format/quality/resolution).

Unknown non-None values now raise ValueError the same way; None keeps
its meaning as the default. Tests for each helper; they fail on main.
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.

1 participant