mikebridge commented on code in PR #42863: URL: https://github.com/apache/superset/pull/42863#discussion_r3731852408
########## superset/migrations/versions/2026-08-06_18-00_b8d2f4a6c901_index_purge_audit_predecessor.py: ########## @@ -0,0 +1,43 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +"""index purge audit predecessor lookup + +Revision ID: b8d2f4a6c901 +Revises: c4a1b8e2d739 +Create Date: 2026-08-06 18:00:00.000000 + +""" + +from superset.migrations.shared.utils import create_index, drop_index + +# revision identifiers, used by Alembic. +revision: str = "b8d2f4a6c901" +down_revision: str = "c4a1b8e2d739" Review Comment: Refuted — this suggestion would cause the exact failure it predicts. Alembic revision chains are **linear and time-ordered, not grouped by table**: a new migration must chain off the repository's current head, and `c4a1b8e2d739` *is* the head this branch was cut from (it merged to master the same morning; verified no other migration points at it). The resulting chain `1a27941d5352 → c4a1b8e2d739 → b8d2f4a6c901` is single-headed — confirmed by the pre-push single-alembic-head check. Re-pointing `down_revision` at `e7d93a524ff6` (the July migration that created the table) would **fork the history into two heads** and break `alembic upgrade`. Which table a migration touches has no bearing on its position in the chain. _(Reply prepared with AI assistance (Claude), on behalf of and reviewed by @mikebridge.)_ ########## superset/tasks/deletion_retention.py: ########## @@ -280,7 +280,17 @@ def _purge_one( removed_dashboard_slices=result.removed_dashboard_slices, ) elif result.blocked_reason is not None: - audit.block(record_id) + disposition: audit.RetentionBlockedDisposition = ( + audit.finalize_retention_blocked(record_id) + ) + if disposition == "suppressed": + stats_logger_manager.instance.incr( + f"{_METRIC_PREFIX}.blocked_audit_suppressed" + ) + elif disposition == "fallback": + stats_logger_manager.instance.incr( + f"{_METRIC_PREFIX}.blocked_audit_dedupe_fallback" + ) Review Comment: Refuted as out of scope by the feature spec, with the underlying concern already covered by a different mechanism. The spec deliberately enumerates **exactly two** counters (FR-013: successful redundant-record suppression, fail-safe fallback) and fences additional observability polish out of this feature (FR-011). The visibility this thread asks for is guaranteed by FR-012: every blocked evaluation — retained or suppressed — still contributes to the scheduled run's blocked count and the existing blocked gauge, so `retained` outcomes are not silent. A dedicated counter for `retained` would mostly measure the routine path (every first-blocked outcome and every status transition) that the gauge already reports. Happy to consider it in the separately-scoped observability follow-up if there's a concrete alerting need. _(Reply prepared with AI assistance (Claude), on behalf of and reviewed by @mikebridge.)_ -- 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]
