[MODEL] Delete 500Gb data 600M database

Open 💬 1 comment Opened Jul 5, 2026 by hack-boop

Preflight Checklist

  • [x] I have searched existing issues for similar behavior reports
  • [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

We were enhancing code and claude was asked to recalucalte data and it droped the tables.

What Claude Actually Did

Incident summary
When: While implementing the Scanner/Campaigns redesign (the direction-data fix + B12 tier redesign), after finishing the code changes to setup_scanner.py, inflection_cache.py, and server.py, I needed to apply the new schema columns (signal_tier, secondary_*, etc.) to the live database.

The command:

from db.pg_conn import get_conn
from db.pg_init import init_db
conn = get_conn()
init_db(conn) # <- this line
conn.commit()
The mistake: init_db's actual signature is init_db(drop_existing: bool = False, skip_indexes: bool = False) — it does not take a connection object at all; it opens its own connection internally. I called it as init_db(conn) without checking the signature first. Python bound conn (a psycopg2 connection object, which is truthy) to the first parameter, drop_existing. So the call was effectively init_db(drop_existing=<truthy>).

What that triggered: pg_init.py's init_db(), when drop_existing is truthy, loops over a hardcoded list (DROP_ORDER, db/pg_init.py:1185) and runs DROP TABLE IF EXISTS {t} CASCADE for each one, then recreates the empty schema. The function even logged it: "drop_existing=True — dropping all tables" — I saw that log line and immediately stopped and checked row counts rather than continuing.

Tables destroyed (in DROP_ORDER, confirmed 0 rows after): raw_trades, raw_chain_snapshots, sweep_clusters, classified_trades, iv_history, iv_rank_cache, inflection_cache, setup_cache, daily_flow_rollup, market_prices, whale_sessions, whale_outcome_tracker, activity_z_cache, position_lifecycle, earnings_calendar, regime_state, session_summary, net_drift_snapshots, gex_levels, trading_calendar, ticker_metadata, news_sentiment, news_raw.

Tables that happened to survive (simply not in that hardcoded list — a pre-existing gap, not something either of us did): contract_session_flow (797,791 rows, 4/1–7/2), daily_oi_snapshots (15.3M rows, 4/24–7/2), eod_runs (125 rows, which is how I was able to pull real historical timing data for you afterward).

Root cause, one sentence: I ran a function against a live production database without first reading its signature or considering what it would do, on a system I had already been told multiple times is live.

Expected Behavior

Recalculate data base on 30 days rwa data

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

_No response_

Claude Model

Sonnet

Relevant Conversation

Impact

Critical - Data loss or corrupted project

Claude Code Version

Claude Code version: 2.1.118

Platform

Anthropic API

Additional Context

-Python project and postgressDB
This is rediculous my 6 months effort blown away just like that

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗