eschutho opened a new pull request, #42388: URL: https://github.com/apache/superset/pull/42388
### SUMMARY Kills [SUPERSET-PYTHON-YDB](https://preset-inc.sentry.io/issues/SUPERSET-PYTHON-YDB) — `DatabaseError: ... Cannot parse as CloudRegion` — ~90k occurrences across 24 users, firing since 2025-12. ### PROBLEM `DatetimeFormatDetector.detect_column_format()` opportunistically samples a temporal column to pre-compute its datetime format when a dataset is saved. It already wraps the entire method body in `except Exception: logger.exception(...); return None`, so any failure here is fully handled and has zero user-facing impact — format detection is simply skipped. The observed Sentry error is a genuine BigQuery-side 400 rejection ("Cannot parse '' as CloudRegion") from `database.get_df()`, coming from a specific customer's misconfigured/unreachable BigQuery connection. Because the whole method shared one broad `except Exception`, this already-handled, environment-dependent failure was logged via `logger.exception()` (ERROR + full traceback), which Sentry's logging integration captures as an issue on every single occurrence. ### FIX Wrap only the `database.get_df()` call in its own `try/except`, logging at WARNING instead — matching the log level already used a few lines below for the sibling "No data returned" / "Could not detect format" cases. The outer `except Exception` is untouched, so genuine internal bugs (SQL building, identifier quoting, etc.) still log at ERROR and stay visible/actionable. No functional/behavioral change: `detect_column_format()` still always returns `None` on any failure; `detect_all_formats()` callers are unaffected. ### TRADEOFFS Query-execution failures against the *customer's own database* during this specific best-effort operation no longer create a Sentry issue. Real connectivity/auth problems with that database are still visible elsewhere (e.g. when the customer actually queries the dataset/chart, which raises separate, already-tracked Sentry issues) — this only mutes the redundant, non-actionable copy that fired on every dataset save against a broken connection. ### FOLLOW-UP (not in this PR) The underlying BigQuery connection issue (empty/invalid `location`) is a customer-side configuration problem, not a Superset bug. ### TESTING INSTRUCTIONS - Updated `tests/unit_tests/datasets/test_datetime_format_detector.py`: the existing error-handling test now asserts WARNING-only (no ERROR) on a `get_df` failure; a new test asserts a genuine internal error (`get_sqla_engine` raising) still logs at ERROR. - `pytest tests/unit_tests/datasets/test_datetime_format_detector.py` — 12 passed. - `ruff check` + `ruff format --check` clean. Shortcut: [sc-115217](https://app.shortcut.com/preset/story/115217) 🤖 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]
