Skip to content

REST: Keep vended storage credentials for staged tables - #4329

Open
Anurag-S1ngh wants to merge 1 commit into
apache:mainfrom
Anurag-S1ngh:fix/4325-staged-table-vended-credentials
Open

Anurag-S1ngh wants to merge 1 commit into
apache:mainfrom
Anurag-S1ngh:fix/4325-staged-table-vended-credentials

Conversation

@Anurag-S1ngh

Copy link
Copy Markdown

Rationale for this change

A staged REST create returns no metadata-location, but _response_to_staged_table matched the vended storage-credentials against that missing location. _resolve_storage_credentials returns {} for a falsy location, so the staged table's FileIO never received the credentials and writes fell back to ambient credentials or failed without them. create_table with the same response kept the credentials.

The staged path now matches against the table location from metadata.location, with a trailing slash so a credential prefix like gs://bucket/ns/t/ matches, while create_table is unchanged.

Are these changes tested?

Yes. tests/catalog/test_rest.py::test_create_staged_table_with_storage_credentials returns a staged response with storage-credentials and no metadata-location, then asserts the vended token reaches the staged table's FileIO. On main the test fails with KeyError: 'gcs.oauth2.token'.

Full unit suite: 4532 passed, 5 skipped. prek run -a passes.

Are there any user-facing changes?

Yes. create_table_transaction now keeps the vended storage credentials returned by the REST catalog for staged creates, matching the behavior of create_table.

Closes #4325

This branch has not been deployed

No deployments
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.

REST: create_table_transaction drops vended storage-credentials

1 participant