geyanggang opened a new issue, #12734:
URL: https://github.com/apache/gravitino/issues/12734
### Version
main branch
### Describe what's wrong
When altering a table through the Flink connector and the resolved change
set is empty (nothing actually changes), the connector still forwards an empty
update list to Gravitino. The server rejects the empty update list, so an
effectively no-op ALTER TABLE fails instead of succeeding as a no-op.
This affects three code paths in flink-connector/flink-common:
1. GravitinoHiveCatalog.applyGenericTableAlter — a generic (non-native)
table alter where neither properties nor comment change. Affects generic tables
(e.g. Kafka-backed tables) on the Hive catalog.
2. BaseCatalog.alterTable(tablePath, newTable, ignoreIfNotExists) — this
path diffs only the comment; when the comment is unchanged the change set is
empty. Affects all catalog types.
3. BaseCatalog.alterTable(tablePath, newTable, tableChanges,
ignoreIfNotExists) — when Flink passes an empty tableChanges list. Affects all
catalog types.
In each case the connector calls TableCatalog.alterTable(identifier,
emptyChanges), and server-side TableUpdatesRequest.validate() throws because
the update list must not be empty.
### Error message and/or stacktrace
org.apache.flink.table.api.TableException: Could not execute AlterTable in
path `flink_catalog`.`db`.`tbl`
at
org.apache.flink.table.catalog.CatalogManager.execute(CatalogManager.java:1401)
at
org.apache.flink.table.catalog.CatalogManager.alterTable(CatalogManager.java:1264)
...
Caused by: org.apache.flink.table.catalog.exceptions.CatalogException:
java.lang.IllegalArgumentException: updates must not be empty
at
org.apache.gravitino.flink.connector.hive.GravitinoHiveCatalog.applyGenericTableAlter(GravitinoHiveCatalog.java:315)
at
org.apache.gravitino.flink.connector.hive.GravitinoHiveCatalog.alterTable(GravitinoHiveCatalog.java:265)
at
org.apache.flink.table.catalog.CatalogManager.lambda$alterTable$30(CatalogManager.java:1267)
at
org.apache.flink.table.catalog.CatalogManager.execute(CatalogManager.java:1395)
... 32 more
Caused by: java.lang.IllegalArgumentException: updates must not be empty
at
org.apache.gravitino.shaded.com.google.common.base.Preconditions.checkArgument(Preconditions.java:143)
at
org.apache.gravitino.dto.requests.TableUpdatesRequest.validate(TableUpdatesRequest.java:60)
at
org.apache.gravitino.client.RelationalCatalog.alterTable(RelationalCatalog.java:246)
at
org.apache.gravitino.flink.connector.hive.GravitinoHiveCatalog.applyGenericTableAlter(GravitinoHiveCatalog.java:315)
at
org.apache.gravitino.flink.connector.hive.GravitinoHiveCatalog.alterTable(GravitinoHiveCatalog.java:265)
... 35 more
### How to reproduce
1. Gravitino version: main branch.
2. Register a catalog through the Flink connector.
3. Trigger a no-op ALTER TABLE. Any of the following reproduces it:
- [ ] On a generic table (e.g. is_generic=true, a Kafka-backed table
under the Hive catalog): run an ALTER TABLE ... SET (...) whose resolved result
is identical to the current table (same options, same comment). This is common
with idempotent alters at job startup.
- [ ] Alter a table so that only the comment path is exercised and the
comment is unchanged.
- [ ] Invoke alter with an empty Flink tableChanges list.
4. The alter fails with IllegalArgumentException: updates must not be empty
instead of succeeding as a no-op.
### Additional context
Root cause: the connector builds a Gravitino TableChange[] purely from diffs
(comment change, removed properties, changed/added properties, or converted
Flink column/option changes). When there is no diff the array is empty, but the
connector still calls TableCatalog.alterTable(identifier, emptyChanges).
Server-side TableUpdatesRequest.validate() requires a non-empty update list:
`Preconditions.checkArgument(!updates.isEmpty(), "updates must not be
empty");`
The fix is to treat an empty change set as a no-op and skip the call in all
three paths. This is a latent bug introduced with the Flink generic-table
support (#9504 / PR #9689) and carried through the multi-version refactor
(#10541 / PR #10517); it is not specific to any single catalog implementation.
--
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]