Drop auction_orders Table

[AryanGodara]

Description

Follow-up to #4568, which stopped using the auction_orders table and switched the order->auction lookup to the GIN index on competition_auctions.order_uids (V112). This drops the now-unused table, as a follow-up (hotfix) release after V112.

Drop is a fast, metadata-only Flyway migration (prior auction_orders drop in V092 took 55 ms on prod) — no manual step needed despite the table's size.

Changes

• Add V113__drop_auction_orders.sql: DROP TABLE IF EXISTS auction_orders.

How to test

No manual step needed as DROP TABLE on an unused table is metadata-only and
instant. CI runs the full migration set; confirm it applies cleanly.

Related Issues

Partially addresses #3057.

[github-actions]

Reminder: Please update the DB Readme and comment whether migrations are reversible (include rollback scripts if applicable).

• If creating new tables, update the tables list.
• When adding a new index, consider using CREATE INDEX CONCURRENTLY for tables involved in the critical execution path.
• For breaking changes, remember that during rollout k8s starts the new autopilot, runs the Flyway migration, and only then shuts down the old pod. That overlap means the previous version can still be processing requests on the migrated schema, so make it compatible first and ship the breaking DB change in the following release.

---

Caused by:

• database/sql/V113__drop_auction_orders.sql

[claude]

Claude finished @AryanGodara's task in 1m 40s —— View job

---

PR Review: Drop auction_orders Table

• Read changed migration file
• Verify no code still references auction_orders
• Check migration versioning & DB README/tables list
• Post review findings

Verdict: LGTM ✅

Clean, minimal, correct follow-up to #4568. I verified the substance rather than just the diff:

• Replacement lookup path is in place. The order→auction query now uses the array-containment operator backed by the V112 GIN index — crates/database/src/auction.rs:118: SELECT id FROM competition_auctions WHERE order_uids @> ARRAY[$1::bytea] ORDER BY id. The GIN index (competition_auctions_order_uids_gin) exists as of V112, so the dropped auction_orders_by_order_uid index has a functional replacement.
• No remaining references to the table. Grep across the database crate finds zero uses of auction_orders. The only hits elsewhere are a local variable named auction_orders in crates/autopilot/src/infra/persistence/mod.rs:458 (unrelated to the table).
• No dependents to break the drop. No foreign keys or views reference the table, so a plain DROP TABLE (no CASCADE) is correct — avoiding CASCADE is the right call, as it would surface any unexpected dependency instead of silently dropping it.
• Idempotent. DROP TABLE IF EXISTS is safe to re-run and safe on networks where the table may already be absent.
• Versioning is clean. V113 is the highest migration number; no conflicts. (The table's create/drop history — V065→V092→V106→V113 — is fine under Flyway's linear versioning.)

Notes (non-blocking)

• Rollout gating — the "do not merge until V112 is fully rolled out" warning is the one real risk here, and it's already documented in the PR body, so I won't belabor it. Worth confirming flyway_schema_history shows version 112 on every network and no pre-Replace auction_orders table with index on order_uids column #4568 pods remain before merge.
• Irreversibility (re: the CI reminder) — DROP TABLE is not reversible, but the data was a pure duplicate of competition_auctions.order_uids, so there's no unique information lost. No rollback script needed.
• No README/tables-list changes required — auction_orders was never documented in database/README.md nor listed in crates/database/src/lib.rs TABLES, so there's nothing to remove there.

No inline comments — I didn't find anything that should lead to a code change.
• aryan/drop-auction-orders-table

[claude]

Claude finished @AryanGodara's task in 52s —— View job

---

PR Review: Drop auction_orders Table

• Read changed migration file
• Verify no code still references auction_orders
• Verify replacement lookup path (V112 GIN index)
• Check migration versioning
• Post review findings

Verdict: LGTM ✅

Correct, minimal follow-up to #4568. Verified the substance:

• Replacement lookup is live. crates/database/src/auction.rs:118 uses order_uids @> ARRAY[$1::bytea], backed by the competition_auctions_order_uids_gin index created in V112. The dropped auction_orders_by_order_uid index has a functional replacement.
• No live references to the table. The only non-migration hit — crates/autopilot/src/infra/persistence/mod.rs:458 — is a local HashSet variable named auction_orders, unrelated to the table.
• Plain DROP TABLE (no CASCADE) is right. No FKs/views depend on it; avoiding CASCADE would surface any surprise dependency rather than silently dropping it. IF EXISTS makes it idempotent and safe on networks where the table is already absent.
• Versioning is clean. V113 is the highest number. The create/drop churn (V065 → V092 drop → V106 recreate → V113 drop) is fine under Flyway's linear ordering.
• No README/tables-list changes needed — auction_orders was never in database/README.md nor crates/database/src/lib.rs TABLES.

Notes (non-blocking)

• Rollout gate — the one real risk is merging before V112 is fully rolled out, already called out in the PR body. Confirm flyway_schema_history shows version 112 on every network and no pre-Replace auction_orders table with index on order_uids column #4568 pods remain before merging.
• Irreversibility (CI reminder) — DROP TABLE isn't reversible, but the data was a pure duplicate of competition_auctions.order_uids, so no unique information is lost and no rollback script is warranted.

No inline comments — nothing here should lead to a code change.
• aryan/drop-auction-orders-table

[MartinquaXD]

Looks like we didn't have documentation for this table in the first place so LGTM.