[#10134] fix(catalog): prevent NPE when filesetChanges is null

[a638011]

What changes were proposed in this pull request?

Fix a potential NullPointerException in AlterFilesetFailureEvent when filesetChanges is null.

Why are the changes needed?

When filesetChanges is null, the constructor calls filesetChanges.clone() which throws NPE. This can happen in failure scenarios where the changes array is not available.

Fix issue #10134

Does this PR introduce any user-facing changes?

No

How was this patch tested?

Added unit test AlterFilesetFailureEventTest that verifies null filesetChanges does not throw NPE.

[justinmclean]

@a638011, can you please fix up the PR title to include the issue number? Can you please also request an issue before working on it, so it can be assigned to you.

[a638011]

Hi @justinmclean, thanks for the feedback! I'll update the PR title to include the issue number in the proper format and request the issue for assignment. Could you clarify the expected format?

[justinmclean]

@a638011 We use spotless to make sure code is consistently formatted. You'll need to run ./gradlew :core:spotlessApply and push your changes to correct the CI failure.

[a638011]

Thanks @justinmclean! I'll run ./gradlew :core:spotlessApply locally and push the changes. The CI is taking a while to run spotless, so I'll update once the formatting is applied.

[github-actions]

Code Coverage Report

Overall Project	64.78%	🟢
Files changed	100.0%	🟢

Module	Coverage
aliyun	1.73%	🔴
api	46.15%	🟢
authorization-common	85.96%	🟢
aws	1.1%	🔴
azure	2.6%	🔴
catalog-common	10.0%	🔴
catalog-fileset	80.02%	🟢
catalog-hive	80.98%	🟢
catalog-jdbc-clickhouse	77.71%	🟢
catalog-jdbc-common	36.84%	🔴
catalog-jdbc-doris	80.94%	🟢
catalog-jdbc-hologres	57.71%	🟢
catalog-jdbc-mysql	79.23%	🟢
catalog-jdbc-oceanbase	78.38%	🟢
catalog-jdbc-postgresql	81.22%	🟢
catalog-jdbc-starrocks	78.27%	🟢
catalog-kafka	77.01%	🟢
catalog-lakehouse-generic	45.07%	🟢
catalog-lakehouse-hudi	79.1%	🟢
catalog-lakehouse-iceberg	87.15%	🟢
catalog-lakehouse-paimon	77.71%	🟢
catalog-model	77.72%	🟢
cli	44.51%	🟢
client-java	77.73%	🟢
common	49.13%	🟢
core	81.2%	🟢
filesystem-hadoop3	76.97%	🟢
flink	38.86%	🔴
flink-runtime	0.0%	🔴
gcp	14.2%	🔴
hadoop-common	10.39%	🔴
hive-metastore-common	45.82%	🟢
iceberg-common	50.21%	🟢
iceberg-rest-server	66.24%	🟢
integration-test-common	0.0%	🔴
jobs	62.55%	🟢
lance-common	23.78%	🔴
lance-rest-server	57.84%	🟢
lineage	53.02%	🟢
optimizer	74.88%	🟢
server	85.76%	🟢
server-common	68.6%	🟢
spark	35.09%	🔴
spark-common	39.88%	🔴
trino-connector	31.62%	🔴

Files

Module	File	Coverage
core	AlterFilesetFailureEvent.java	100.0%	🟢

[yuqi1129]

filesetChanges could not be null. Please refer to the following code

gravitino/server/src/main/java/org/apache/gravitino/server/web/rest/FilesetOperations.java

Lines 298 to 302 in fbffe05

	FilesetChange[] changes =
	request.getUpdates().stream()
	.map(FilesetUpdateRequest::filesetChange)
	.toArray(FilesetChange[]::new);
	Fileset t = dispatcher.alterFileset(ident, changes);

[justinmclean]

That's only partially true. In the REST path, changes are indeed non-null. But AlterFilesetFailureEvent is not REST-specific. It is built in a generic dispatcher (see FilesetEventDispatcher.java) from varargs FilesetChange... changes.

Java varargs can be called with a null array (e.g. alterFileset(ident, (FilesetChange[]) null)), and the API does notenforce non-null (see FilesetCatalog.java)