yuqi1129 commented on PR #12547:
URL: https://github.com/apache/gravitino/pull/12547#issuecomment-5392946800
The current tests cover the basic rendering and several individual states
well, but the state-transition matrix is not complete yet. Please add coverage
for the following cases before merge:
1. **Existing registered connector + refresh failure.** Put a real
`CatalogConnectorContext` in the manager, then make `metalake.loadCatalog()`
fail. Also cover an unregister failure. Assert that `catalog_status`,
`catalogConnectorExist()`, and the expected `SHOW CATALOGS` presence remain
consistent. The current tests mostly exercise catalogs that were never added to
`catalogConnectors`, so they do not cover the production lifecycle of an
already registered catalog.
2. **Unknown catalog type conversion.** Make `metalake.loadCatalog()` throw
`UnsupportedOperationException("Unsupported catalog type: ...")` and verify
that the row is reported as `UNSUPPORTED`, not `FAILED`.
3. **Reload and delete transitions with an existing connector.** Cover:
unchanged refresh, successful reload, unregister-success/register-failure,
successful deletion, and unregister failure. Verify status, failure count,
last-success time, connector-map membership, and registration/unregistration
calls for every transition.
4. **Deleted metalake cleanup.** Extend
`testStateOfAVanishedMetalakeIsPruned` to create registered connector contexts
and verify cleanup of `catalogStates`, `metalakeErrors`, `metalakes`,
`catalogConnectors`, and the Trino catalogs, rather than checking only the
first two maps.
5. **Multi-metalake isolation.** Use two entry catalogs/factories sharing
the same `CatalogConnectorManager`, with catalogs and errors in both metalakes.
Verify that `system.catalog`, `catalog_status`, and the per-metalake part of
`load_status` expose only the entry catalog's metalake. Include a skip pattern
that matches the qualified Trino catalog name.
6. **Atomic load-status snapshot.** Read `load_status` concurrently with a
failing/recovering refresh and assert that one row cannot combine fields from
two different load attempts.
7. **Initialization recovery.** Change the factory test from "fails twice"
to "first initialization fails, the underlying condition is fixed, and the
second create succeeds". Also verify that the failed manager/JDBC
connection/driver/executor is cleaned up.
8. **Query/integration coverage.** Add `count(*)`/zero-projected-column
coverage, query the status tables after an actual registration failure, and run
at least one coordinator + separate worker scenario to verify that status-table
splits are served by the coordinator.
The key invariant is that `catalog_status`, `load_status`, manager connector
membership, and `SHOW CATALOGS` must describe the same state after every
failure and recovery transition.
--
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]
