From 2a4cb829fe422ca035a83448aa21ab5c511003f5 Mon Sep 17 00:00:00 2001 From: hailin Date: Mon, 12 Jan 2026 21:00:34 -0800 Subject: [PATCH] fix(deploy-mining): truncate processed_cdc_events after CDC offset reset Problem: full-reset script resets Kafka consumer offsets but doesn't clear the processed_cdc_events table. When migrations run, containers may start and consume CDC events, inserting records into this table. After offset reset, the service restarts and detects all events as "duplicates" because the idempotency records still exist. Solution: Add TRUNCATE processed_cdc_events step after CDC offset reset in Step 8, before starting services. This ensures the idempotency table is in sync with the Kafka offset position. Co-Authored-By: Claude Opus 4.5 --- backend/services/deploy-mining.sh | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/backend/services/deploy-mining.sh b/backend/services/deploy-mining.sh index 61a2054a..a499b330 100755 --- a/backend/services/deploy-mining.sh +++ b/backend/services/deploy-mining.sh @@ -991,6 +991,17 @@ full_reset() { fi done + # 清空 processed_cdc_events 表（因为 migration 时可能已经消费了一些消息） + # 这是事务性幂等消费的关键：重置 Kafka offset 后必须同时清空幂等记录 + log_info "Truncating processed_cdc_events tables to allow re-consumption..." + for db in "rwa_contribution" "rwa_auth"; do + if run_psql "$db" "TRUNCATE TABLE processed_cdc_events;" 2>/dev/null; then + log_success "Truncated processed_cdc_events in $db" + else + log_warn "Could not truncate processed_cdc_events in $db (table may not exist yet)" + fi + done + log_step "Step 9/18: Starting 2.0 services..." for service in "${MINING_SERVICES[@]}"; do service_start "$service"