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.

Warning

Do not merge until the V112 release is fully rolled out on all networks.
The old autopilot code still writes to auction_orders; dropping it while any
old pod is live breaks that write path. Gate: flyway_schema_history shows
version 112 on every network and no pre-#4568 pods remain.

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