laserninja opened a new pull request, #11634: URL: https://github.com/apache/gravitino/pull/11634
### What changes were proposed in this pull request? Derive the advertised endpoint set in `/v1/config` from the backing catalog's capabilities rather than a hardcoded static list. Specifically, gate the `V1_SUBMIT_TABLE_SCAN_PLAN` endpoint behind `CatalogWrapperForREST.supportsScanPlanOperations()`, which returns `true` for non-REST backends (Hive, JDBC, Memory, Custom) where Gravitino performs scan planning locally, and `false` for REST backends where the upstream catalog owns scan planning. ### Why are the changes needed? `IcebergConfigOperations` advertises a hardcoded `DEFAULT_ENDPOINTS` list (including `V1_SUBMIT_TABLE_SCAN_PLAN`) for every catalog, regardless of whether the configured backend actually supports those operations. A client that trusts the advertised `endpoints` may call an operation the backend cannot serve, producing confusing runtime errors. Fix: #11584 ### Does this PR introduce _any_ user-facing change? REST backend catalogs will no longer advertise the scan plan endpoint in the `/v1/config` response. Clients that rely on the advertised endpoints will now correctly see only the operations their catalog backend supports. ### How was this patch tested? - Added `TestIcebergConfigEndpointGating` with tests verifying scan plan endpoint is omitted when not supported, and core endpoints are always present. - Added `testConfigEndpointsContainScanPlanForNonRESTBackend` to `TestIcebergConfig` verifying scan plan IS advertised for non-REST backends. - All existing tests pass (11 tests, 0 failures). -- 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]
