yuqi1129 opened a new issue, #13895:
URL: https://github.com/apache/gravitino/issues/13895
### Version
main branch (`95ce9f5a230decdfabb5249c0d7910543a32402c`, Iceberg 1.11.0)
### Describe what's wrong
Loading an Iceberg view through `IcebergCatalogWrapper.loadView` can throw
`NullPointerException: metadata` when the view is renamed natively during
loading. A missing old name should produce `NoSuchViewException` instead.
Iceberg's `BaseMetastoreViewCatalog.loadView` checks existence using one
`ViewOperations` instance, then creates another for the returned `BaseView`. If
a native rename happens between those instances, the latter can return null
metadata. `CatalogHandlers.viewResponse` passes that null to the response
builder.
### Error message and/or stacktrace
```text
java.lang.NullPointerException: metadata
at java.util.Objects.requireNonNull
at
org.apache.iceberg.rest.responses.ImmutableLoadViewResponse$Builder.metadata
at org.apache.iceberg.rest.CatalogHandlers.viewResponse
at org.apache.iceberg.rest.CatalogHandlers.loadView
at org.apache.gravitino.iceberg.common.ops.IcebergCatalogWrapper.loadView
```
### How to reproduce
1. Initialize an Iceberg JDBC catalog with schema version V1 and create
`views.old_name`.
2. Load the view through `IcebergCatalogWrapper` while a native catalog
client renames it to `views.new_name`, after the first operations instance's
existence check and before the second instance reads metadata.
3. The old-name load throws the metadata NPE; the new name remains readable.
The race can be reproduced deterministically in a regression test by
overriding `JdbcCatalog.newViewOps` to perform the rename immediately before
returning the second operations instance for the old name. No sleep or thread
scheduling is needed.
### Additional context
The failure is in the shared Iceberg wrapper, so it affects both the Iceberg
REST and Gravitino catalog loading paths. Constructing the response from a
checked metadata snapshot can preserve the existing not-found contract.
--
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]
