Re: [PR] (fix) Fixed IcebergCatalog stale FileIO after metadata refresh [polaris]

["dimas-b (via GitHub)" <gi...@apache.org>]

dimas-b commented on code in PR #3494:
URL: https://github.com/apache/polaris/pull/3494#discussion_r2712993852


##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergCatalog.java:
##########
@@ -1409,6 +1409,22 @@ public void doRefresh() {
                       Set.of(PolarisStorageActions.READ, PolarisStorageActions.LIST));
               return TableMetadataParser.read(fileIO, metadataLocation);
             });
+
+        // After a refresh, re-load the FileIO with the new table metadata properties to
+        // ensure the right permissions are present for subsequent file system interactions.
+        if (currentMetadata != null) {
+          tableFileIO =
+              loadFileIOForTableLike(
+                  tableIdentifier,
+                  StorageUtil.getLocationsUsedByTable(currentMetadata),
+                  resolvedEntities,
+                  new HashMap<>(currentMetadata.properties()),
+                  Set.of(
+                      PolarisStorageActions.READ,
+                      PolarisStorageActions.WRITE,
+                      PolarisStorageActions.LIST));

Review Comment:
   Why do we request R/W access for FileIO in a "refresh" method?
   
   Having to reset `tableFileIO` in this context sounds like a design issue to me. I'd think access level (Read / Write / List) should be decided per use case (load vs. commit, etc.).
   
   WDYT?



-- 
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: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org