Revanth14 opened a new issue, #2181: URL: https://github.com/apache/iceberg-go/issues/2181
### Feature Request / Improvement ## Context Found while reviewing #2163 ## Current behavior - Plan-scoped IO (`prefixScopedIO.propertiesForLocation`) replaces: `clearOverriddenCredentialProperties` drops the base S3 key pair and session token, GCS token, or matching ADLS SAS before merging the vended config. - The table-wide sites layer: Create/Register/Load, `RefreshTableCredentials`, and refresher renewal call `mergeVendedCredentials` without clearing, so vended keys are copied over the base config and anything not vended is kept. The only exception is a nonempty `adls.token`, which clears the credentials that would shadow it. - `TestTableResponseLayersPartialS3Credential` pins the layering behavior. ## Problem An STS session token is only valid with the temporary key pair it was issued with. Layering a vended `s3.session-token` onto a static key pair yields a credential that cannot work. Likewise, a stale `s3.session-token` left in the config next to a newly vended key pair gets a 403. ## Java Java layers when it builds clients: `S3FileIO` and `GCSFileIO` merge `storageCredential.config()` over the FileIO properties with no clearing. On refresh, though, `VendedCredentialsProvider` treats an S3 credential as a complete unit: it requires the access key, secret, session token, and expiry, and builds the credentials from the vended config alone. ## Proposal Replace per credential type at the table-wide sites, matching plan-scoped IO and Java's refresh path, by routing them through `clearOverriddenCredentialProperties`. Update `TestTableResponseLayersPartialS3Credential` to pin replacement. This diverges from Java's initial client construction, which layers. ## Open question Is there a case where layering is intended, for example a server that vends only a refreshed session token and expects the client to keep its key pair? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
