Conversation
StorageAnalyticsClient.list sent sort_column and sort_order as query parameters. GET /iceberg/bucket only reads sortColumn and sortOrder and ignores unknown keys, so both options were silently dropped and buckets always came back in the default order. Use the wire names, matching the server schema and storage-js. Applies to the async client and its generated sync twin. Fixes supabase#1635
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce?
Bug fix.
What is the current behavior?
Fixes #1635
StorageAnalyticsClient.list()builds its query string with snake_case sort keys:GET /iceberg/bucketonly readssortColumnandsortOrder(server schema), and it ignores unknown query keys. Both options are therefore silently dropped, andlist(sort_column="created_at", sort_order="desc")returns buckets in the default order.limit,offsetandsearchwork only because they are spelled the same in both conventions.What is the new behavior?
The query string uses
sortColumn/sortOrder, matching the server schema and storage-js (StorageAnalyticsClient.listBuckets). The Python keyword arguments are unchanged, so this is not an API change.The async client and its generated sync twin had the same lines, and both are updated.
Related: #1632 / #1633 fix the same snake_case/camelCase mismatch in the vectors
list_indexes()request body. That is a different endpoint and module, so this is a separate PR.Tests
test_async_analytics_list_sends_camel_case_sort_paramsandtest_sync_analytics_list_sends_camel_case_sort_paramsinsrc/storage/tests/test_client.pycalllist()on a real client over anhttpx.MockTransportand assert the exact query parameters sent to/iceberg/bucket. Both fail onmain(the query hassort_column/sort_order) and pass here. The analytics client had no test coverage before.Validation
uv run --package storage3 pytest tests/test_client.py tests/test_utils.py tests/test_exceptions.py: 32 passed.uv run --package storage3 --group mypy mypy src/storage3 tests: no issues in 33 source files.uv run ruff check --fix/uv run ruff format: clean.git diff --check: clean.tests/_asyncandtests/_syncare integration tests that need the storage stack frommake storage.start-infra(Docker + Supabase CLI), which was not running. They fail withhttpx.ConnectError: 50 errors onmainand 50 with this change, and the only difference in the passed count is the two new tests.