Skip to content

Discrepency in the fetched table properties #3247

@Zevrap-81

Description

@Zevrap-81

Apache Iceberg version

None

Please describe the bug 🐞

I am using Apache Polaris as catalog and when i load the table using pyiceberg, the response has config that is different from what i get when i use Polaris CLI and not only that when i use the file system from this table, i am getting Permission Denied errors, suggesting the credentials in the table are wrong.

Details:

polaris --profile root tables get --catalog "senec_catalog" --namespace "Senec.Stage.Bronze.Ampace_V3LFP" "BmsAmpaceV3ModuleMeasurement"

returns a table with the config property as follows:

, "config": {"s3.path-style-access": "true", "s3.endpoint": "http://localhost:9008"}

however, the rest api cal inside catalog.load_table(table_identifier) has a response that contains the config that looks like this:

{'s3.path-style-access': 'true', 's3.access-key-id': 'NFAIYHBUDHR1VBDHR8G0', 's3.secret-access
-key': 'L4Q_0W4We1ClcHsg8t0A5RcazPu4Xx1TR9P5-fbn', 's3.session-token': '***', 'client.refresh-credentials-endpoint': 'v1/senec_catalog/namespaces/Senec%1FStage%1FBronze%1FAmpace_V3LFP/tables/BmsAmpaceV3ModuleMeasurement/credentials', '
expiration-time': '1776355429000', 's3.endpoint': 'http://localhost:9008', 's3.session-token-e
xpires-at-ms': '1776355429000'}

which would have been okay but using a filesystem created using the io from this table is always resulting in permission errors, so i have to manually set the table properties like so:

        self.tbl.io.properties["s3.endpoint"] = self.catalog.properties["s3.endpoint"]
        self.tbl.io.properties["s3.endpoint"] = self.catalog.properties.get("s3.endpoint")
        self.tbl.io.properties["s3.access-key-id"] = self.catalog.properties.get("s3.access-key-id")
        self.tbl.io.properties["s3.secret-access-key"] = self.catalog.properties.get("s3.secret-access-key")
        self.tbl.io.properties.pop("s3.session-token", None)

Could anyone tell me why is this the case? This is related to #1958 as i am trying to use the filesystem to delete the orphan files.

Willingness to contribute

  • I can contribute a fix for this bug independently
  • I would be willing to contribute a fix for this bug with guidance from the Iceberg community
  • I cannot contribute a fix for this bug at this time

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions