feat(db): add indexes to FK and timestamp columns across all models

[Ananya-CM]

Description

Adds index=True to frequently queried foreign key and timestamp columns
across the model files, and generates the corresponding Alembic migration.
Without these indexes, queries that filter or join on FK columns (e.g.
WHERE session_id = ?) or sort by created_at perform full table scans
as the tables grow.

Related Issues

Closes #1057

Changes Made

Model files — index=True added to FK and timestamp columns:

Model	Columns indexed
AISession	diagnostic_id, verification_id, profile_id, created_at
AISuggestion	session_id, created_at
AIAuditLog	session_id, created_at
ScriptGenerationJob	profile_id, created_at, completed_at
GeneratedScript	job_id, created_at
VerificationResult	report_id, profile_id, created_at
VerificationCheck	result_id, created_at
UninstallFeedback	created_at
ProfilePackage	profile_id, created_at

Note on webhooks table: The webhooks table indexes are excluded
from this migration because the compress_generated_scripts migration
(which creates that table) has a pre-existing type casting bug that
prevents it from running locally. The index=True flags are removed from
webhook.py to keep the model in sync with what can be migrated. Flagging
this for the maintainer to resolve separately.

Alembic migration:

• alembic/versions/039e8649beb5_add_indexes_to_fk_and_timestamp_columns.py
• Based on head 21fe8cc61865
• Applied and verified locally

Verification

• Added unit tests
• Ran pytest tests/ successfully
• Manually tested via the API / CLI
• (If applicable) Generated scripts pass SafetyFilter

Migration applied successfully. All 801 backend tests pass:
801 passed, 679 warnings in 53.45s

Documentation

• Updated docs/FEATURES.md
• Updated CHANGELOG.md
• Code is fully documented and type-hinted

Screenshots

Summary by CodeRabbit

• Performance

  • Added database indexes on frequently used foreign-key and timestamp fields across multiple features.
  • Improves responsiveness for browsing, filtering, and retrieving related or recent records.

• Database

  • Updated the database schema to apply the new indexing changes and keep rollbacks consistent.
  • These improvements reduce lookup time for common queries involving session, profile, job, and verification data.

[vercel]

@Ananya-CM is attempting to deploy a commit to the rishabhmishra0510-5147's projects Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: b1c7ebdf-0e06-4ee2-934a-02e38b72cf20

📥 Commits

Reviewing files that changed from the base of the PR and between 8955597 and d558489.

📒 Files selected for processing (1)

• backend/alembic/versions/039e8649beb5_add_indexes_to_fk_and_timestamp_columns.py

🚧 Files skipped from review as they are similar to previous changes (1)

• backend/alembic/versions/039e8649beb5_add_indexes_to_fk_and_timestamp_columns.py

---

📝 Walkthrough

Walkthrough

This PR adds indexes to selected foreign-key and timestamp columns across nine SQLAlchemy models and introduces an Alembic migration that creates the corresponding indexes concurrently and removes them during downgrade.

Changes

Database Indexing

Layer / File(s)	Summary
Model column index annotations backend/app/models/ai_session.py, backend/app/models/diagnostic.py, backend/app/models/feedback.py, backend/app/models/profile.py, backend/app/models/script_job.py	Adds index=True to selected foreign-key and timestamp columns, including created_at and completed_at.
Alembic migration for indexes backend/alembic/versions/039e8649beb5_add_indexes_to_fk_and_timestamp_columns.py	Defines migration metadata, creates indexes concurrently during upgrade(), and drops them during downgrade().

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: adding indexes to foreign-key and timestamp columns.
Linked Issues check	✅ Passed	The code and migration add the requested indexes for frequently queried foreign-key and timestamp fields, matching #1057.
Out of Scope Changes check	✅ Passed	No clearly unrelated changes are present beyond the requested indexing and migration updates.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

🧹 Nitpick comments (2)

backend/alembic/versions/039e8649beb5_add_indexes_to_fk_and_timestamp_columns.py (2)

21-59: 🚀 Performance & Scalability | 🔵 Trivial | 🏗️ Heavy lift

Index creation will lock affected tables for writes during migration.

op.create_index without postgresql_concurrently=True takes a table-level lock (blocking writes) for the duration of index build on PostgreSQL. The PR's own rationale is that these tables are expected to grow, so on larger production tables this migration could cause a noticeable write-blocking window at deploy time. If any of these tables (e.g. generated_scripts, ai_audit_log) are non-trivial in size in production, consider CREATE INDEX CONCURRENTLY via op.execute with context.autocommit_block(), since concurrent index creation cannot run inside a transaction.

Example pattern using autocommit_block for concurrent index creation

def upgrade() -> None:
    with op.get_context().autocommit_block():
        op.create_index(
            "ix_ai_sessions_diagnostic_id",
            "ai_sessions",
            ["diagnostic_id"],
            postgresql_concurrently=True,
        )
        ...

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@backend/alembic/versions/039e8649beb5_add_indexes_to_fk_and_timestamp_columns.py`
around lines 21 - 59, The index creation in upgrade() uses op.create_index
without concurrent index building, which can block writes on large PostgreSQL
tables. Update the migration to build these indexes concurrently by using the
Alembic context’s autocommit_block() in combination with
postgresql_concurrently=True for the create_index calls in this migration. Keep
the same index names and target tables (for example ai_audit_log,
generated_scripts, and ai_sessions) but switch to the non-locking creation
pattern.

---

23-59: 🚀 Performance & Scalability | 🔵 Trivial | ⚖️ Poor tradeoff

Consider composite indexes for common FK + timestamp filter/sort combos.

Several tables get separate single-column indexes on an FK column and created_at (e.g. ai_audit_log.session_id/created_at, verification_results.profile_id/created_at). If typical queries filter by the FK and order by created_at together, a single composite index (e.g. (session_id, created_at)) would serve both needs more efficiently than two separate indexes and reduce index-maintenance overhead on writes.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@backend/alembic/versions/039e8649beb5_add_indexes_to_fk_and_timestamp_columns.py`
around lines 23 - 59, Replace the separate single-column FK and created_at
indexes in the Alembic migration with composite indexes for the common
filter/sort pairs where queries use both together. Update the index creation in
the migration that adds indexes for ai_sessions, ai_suggestions, ai_audit_log,
script_generation_jobs, generated_scripts, verification_results,
verification_checks, uninstall_feedbacks, and profile_packages so each relevant
table uses a combined foreign-key-plus-created_at index instead of two
independent ones, especially in the migration’s create_index calls.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In
`@backend/alembic/versions/039e8649beb5_add_indexes_to_fk_and_timestamp_columns.py`:
- Around line 21-59: The index creation in upgrade() uses op.create_index
without concurrent index building, which can block writes on large PostgreSQL
tables. Update the migration to build these indexes concurrently by using the
Alembic context’s autocommit_block() in combination with
postgresql_concurrently=True for the create_index calls in this migration. Keep
the same index names and target tables (for example ai_audit_log,
generated_scripts, and ai_sessions) but switch to the non-locking creation
pattern.
- Around line 23-59: Replace the separate single-column FK and created_at
indexes in the Alembic migration with composite indexes for the common
filter/sort pairs where queries use both together. Update the index creation in
the migration that adds indexes for ai_sessions, ai_suggestions, ai_audit_log,
script_generation_jobs, generated_scripts, verification_results,
verification_checks, uninstall_feedbacks, and profile_packages so each relevant
table uses a combined foreign-key-plus-created_at index instead of two
independent ones, especially in the migration’s create_index calls.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 7aa3d0e1-fb7e-4850-9b95-ede5208793fa

📥 Commits

Reviewing files that changed from the base of the PR and between fa65275 and 8955597.

📒 Files selected for processing (6)

• backend/alembic/versions/039e8649beb5_add_indexes_to_fk_and_timestamp_columns.py
• backend/app/models/ai_session.py
• backend/app/models/diagnostic.py
• backend/app/models/feedback.py
• backend/app/models/profile.py
• backend/app/models/script_job.py

[rishabh0510rishabh]

@Ananya-CM Apologies for the delay! Please address the CodeRabbit findings before we can merge this PR.

[Ananya-CM]

@rishabh0510rishabh
Fixed in the latest commit — replaced all op.create_index calls with
CREATE INDEX CONCURRENTLY IF NOT EXISTS executed inside
op.get_context().autocommit_block(), as concurrent index creation cannot
run inside a transaction. This avoids the write-blocking table lock during
migration on larger production tables.

Regarding the composite indexes suggestion — kept separate single-column
indexes since they serve a broader range of queries than composite indexes
would (any query using either column individually benefits, not just queries
filtering by both together). CodeRabbit also flagged this as a "Poor tradeoff".

Migration verified locally: downgrade and upgrade both run cleanly.