Skip to content

chore(db): drop the outbound_number compat view (migration 039)#950

Open
swaroopvarma1 wants to merge 1 commit into
releasefrom
chore/drop-outbound-number-compat-view
Open

chore(db): drop the outbound_number compat view (migration 039)#950
swaroopvarma1 wants to merge 1 commit into
releasefrom
chore/drop-outbound-number-compat-view

Conversation

@swaroopvarma1

@swaroopvarma1 swaroopvarma1 commented Jul 23, 2026 •
edited by coderabbitai Bot
Loading

Copy link
Copy Markdown
Collaborator

What

One migration, one statement: DROP VIEW IF EXISTS outbound_number;

Why

Migration 038 (PR #934) renamed outbound_number → telephony_numbers and left an updatable compatibility VIEW under the old name so pods still running pre-rename code kept working during the rolling deploy. That deploy completed 2026-07-22; every pod has been on post-rename code since, and no rollback is contemplated. The view's insurance window is over.

Safety checks done

  • Swept the repo for references to the bare outbound_number relation (FROM|JOIN|UPDATE|INTO|TABLE|VIEW outbound_number): only historical migration files (never re-run) and Plivo request payload dict keys match. No live SQL touches the view.
  • Applied on the local database: view dropped, telephony_numbers table and row count intact, migrate.py status clean.
  • IF EXISTS guard makes the migration idempotent and safe on environments where the view was never created.

Wire-visible column names (template.outbound_number_id, lead_call_tracker.outbound_number_id) are untouched — they retire via the dual-field API window (separate PR).

Prod

After merge, prod apply is the usual scripts/migrate.py run during the next release — no data movement, metadata-only drop.

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Chores
    • Removed the legacy outbound number compatibility view now that the transition period is complete.

@swaroopvarma2359 @claude
chore(db): drop the outbound_number compatibility view (migration 039)
b63bb72 
Migration 038 renamed outbound_number -> telephony_numbers and left an
updatable compatibility view under the old name as rolling-deploy /
rollback insurance. The rename deployed to prod on 2026-07-22 and all
pods run post-rename code; no live code references the old relation
(verified: only historical migrations and Plivo payload dict keys match).

Applied and verified on the local database: view dropped, table intact.
Prod apply happens via scripts/migrate.py on explicit ops word, as usual.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jul 23, 2026 •
edited
Loading

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8b3af6ea-5915-4256-927d-a6374ddc2241

📥 Commits

Reviewing files that changed from the base of the PR and between 096e3eb and b63bb72.

📒 Files selected for processing (1)
  • app/database/migrations/039_drop_outbound_number_compat_view.sql

Walkthrough

Migration 039 documents the completed rollback-insurance window and conditionally drops the legacy outbound_number compatibility view.

Changes

Outbound number view removal

Layer / File(s) Summary
Drop compatibility view
app/database/migrations/039_drop_outbound_number_compat_view.sql		 Adds migration 039 with context comments and DROP VIEW IF EXISTS outbound_number;.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Poem

I’m a rabbit with SQL in my ear,
Dropping old views with a hop and a cheer.
outbound_number fades from the scene,
Safely removed if it’s still seen.
Carrots applaud the migration routine!

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: dropping the outbound_number compatibility view in migration 039.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch chore/drop-outbound-number-compat-view

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Tara-ag
Tara-ag approved these changes Jul 23, 2026
View reviewed changes

@Tara-ag Tara-ag left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Summary

Files reviewed: 1 (app/database/migrations/039_drop_outbound_number_compat_view.sql)
New issues raised: 0
Decision: Approve ✅

Notes

  • This PR correctly adds a new sequential migration (039_*) rather than editing the existing 038_rename_outbound_number_to_telephony_numbers.sql, satisfying the append-only migration rule.
  • The single statement DROP VIEW IF EXISTS outbound_number; is idempotent and safe for environments where the view may not exist.
  • Cross-checked the repo for live SQL references to the bare outbound_number relation: only historical migration files, wire-visible column names, and Plivo payload dict keys remain. No active queries target the view being dropped.
  • Migration 038’s compatibility view was explicitly documented as temporary and scheduled for removal once pre-rename pods were cycled out.

No blocking or non-blocking issues found. Safe to merge.

@swaroopvarma1 swaroopvarma1 mentioned this pull request Jul 23, 2026
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Tara-ag Tara-ag Tara-ag approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@swaroopvarma1 @Tara-ag @swaroopvarma2359