aminghadersohi opened a new pull request, #44683: URL: https://github.com/apache/superset/pull/44683
### SUMMARY `GET /api/v1/database/<pk>/tables/` validates the requested `schema_name` the same way `GET /api/v1/database/<pk>/schemas/` does before listing tables and views. The schema must be one the database reports (`Database.get_all_schema_names`, using the same cache settings and honouring `force`) and one the user can access (`security_manager.get_schemas_accessible_by_user`). Otherwise the endpoint returns 404 with `Schema not found.`. Details: - The check is in `TablesDatabaseCommand.validate()`. Default catalog resolution and the `supports_schemas` handling moved from `run()` into `validate()`, so the check uses the resolved catalog, and engines without schema support skip it. - Users whose only access is to datasets in the schema can still list that schema's tables, because `get_schemas_accessible_by_user` takes `datasource_access` into account. - Unexpected errors raised during the check return 422 (`DatabaseTablesUnexpectedError`), the same as errors raised while listing tables. - A new command exception, `DatabaseSchemaNotFoundError`, returns 404. The endpoint's OpenAPI spec already listed 404. Behaviour change: requesting tables for an unknown or inaccessible schema now returns 404 instead of 200 with an empty or partial result. ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF N/A ### TESTING INSTRUCTIONS - Unit: `pytest tests/unit_tests/commands/databases/tables_test.py`. New tests cover: unknown schema, inaccessible schema, resolved catalog and `force`, cached schema list (including the list form after deserialization), engines without schema support, and an unexpected error during the check. - Integration: `pytest tests/integration_tests/databases/api_tests.py -k "tables or schemas"`. New tests: `test_database_tables_unknown_schema` (404) and `test_database_tables_dataset_access_only` (a user with access to a single dataset gets 200 and that dataset's table). - Manual: call `/api/v1/database/<pk>/tables/?q=(schema_name:does_not_exist)` and expect 404. A valid schema returns the same result as before. `test_database_tables_unexpected_error` used `schema_name: 'main'`, which exists only on SQLite. On other backends the request now returns 404 before it reaches the mocked error, so the test uses the backend's default schema (`default_schema_backend_map`). The test still checks the same thing: an unexpected error returns 422. Frontend: `useTables` only requests tables for a schema that is in the schemas list. If the endpoint does return an error (e.g. the schema was dropped after the list was loaded), `TableSelector` shows it through its existing error handler, so no UI change is needed. ### ADDITIONAL INFORMATION - [ ] Has associated issue: - [ ] Required feature flags: - [ ] Changes UI - [ ] Includes DB Migration (follow approval process in [SIP-59](https://github.com/apache/superset/issues/13351)) - [ ] Migration is atomic, supports rollback & is backwards-compatible - [ ] Confirm DB migration upgrade and downgrade tested - [ ] Runtime estimates and downtime expectations provided - [ ] Introduces new feature or API - [ ] Removes existing feature or API 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
