[cavidelizade]

Summary

The module join tables (module_issues, module_members, module_links) had no indexes, so every lookup by module_id or issue_id was a sequential scan. The cycle join tables already have the equivalent indexes.

Linked issues

Refs #346 (the index half)

Type of change

• Performance (perf:)

Surface

• API (apps/api/)
• Database migration (apps/api/migrations/)

What changed

Migration 000014 adds idx_module_issues_module, idx_module_issues_issue, idx_module_members_module and idx_module_links_module, using CREATE INDEX IF NOT EXISTS so it's safe to re-run.

Scope note

Issue #346 also flags N+1 association loading in the issue list/detail paths. That's a larger refactor (batching assignees/labels/cycles/modules), so I've left it for a separate PR and kept this one to the indexes.

Migration ordering

I have another open PR (#350) that adds 000013. This one is 000014, so it should merge after #350 to keep the sequence clean. Happy to renumber if you'd prefer.

Test plan

• go build, go vet, go test ./... green; migration applies as plain CREATE INDEX IF NOT EXISTS

AI assistance

• AI tools were used, tool(s): Claude Code (Opus 4.8), commits carry a Co-Authored-By: trailer

Summary by CodeRabbit

• Performance
  • Improved the responsiveness of module-related views by speeding up lookups for associated issues, members, and links.
  • The change applies to existing module data and does not alter what information is displayed or how users interact with these views.

[coderabbitai]

Walkthrough

This migration adds indexes to four module-related lookup columns. Its down migration conditionally removes those indexes.

Changes: Module join indexes

Layer / File(s)	Summary
Create and drop module join indexes apps/api/migrations/000016_module_join_indexes.up.sql, apps/api/migrations/000016_module_join_indexes.down.sql	The up migration conditionally creates indexes on module_issues.module_id, module_issues.issue_id, module_members.module_id, and module_links.module_id. The down migration conditionally drops them.

Priority: Low

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

Change: Other

Suggested reviewers: martian56

Merge Risk: Minimal · up to accba

This change adds lookup indexes on the module join tables, which should speed up queries by module or issue. The index builds run at startup and could briefly slow writes on very large tables, but nothing in the repository shows that the tables are large. It looks safe to merge.

Pre-merge checks: 4 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Description check		The description explains the performance issue, scope, migration ordering, and test results. However, it identifies the migration as 000014 while the changes use 000016, and it omits the required Data…	Update the migration reference from 000014 to 000016. Add the required Database / migrations section with both migration files and idempotency details. Complete the Breaking changes, Rollout notes, and Checklist sections. Use the required i…

Passed checks: 4 passed

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: adding indexes to the module join tables. It follows the required Conventional Commits format and is within the 100-character limit.
Docstring Coverage		No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.)

Full details: Description check

Explanation

The description explains the performance issue, scope, migration ordering, and test results. However, it identifies the migration as 000014 while the changes use 000016, and it omits the required Database / migrations, Breaking changes, Rollout notes, and Checklist sections.

Resolution

Update the migration reference from 000014 to 000016. Add the required Database / migrations section with both migration files and idempotency details. Complete the Breaking changes, Rollout notes, and Checklist sections. Use the required issue-closing format if this PR should close an issue; otherwise state that no issue is being closed.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

_{A rabbit checks each index row,
Four paths help module lookups flow.
The rollback knows what to undo,
With careful hops through SQL too.
Then down the burrow, soft and slow.}

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

[coderabbitai]

🔇 Additional comments: 2

apps/api/migrations/000016_module_join_indexes.up.sql-5-5: 1

5-5: Major · Stability & Availability · Heavy lift

⚠️ Unverified finding
Verification ran but could not confirm this finding. It is shown for review, not as a verified issue.

Avoid blocking writes during the startup migration.

If these join tables contain substantial production data, each standard CREATE INDEX blocks writes to its table until the build finishes. The four builds can therefore interrupt module-association updates during rollout. Use CREATE INDEX CONCURRENTLY in separate migration files: golang-migrate notes that multiple statements in one PostgreSQL execution run in a transaction, where concurrent index creation is not allowed. (postgresql.org)

As per coding guidelines, migrations are “Auto-applied at startup.”

Sources: Coding guidelines, Linters/SAST tools

apps/api/migrations/000016_module_join_indexes.down.sql-1-1: 1

1-1: Major · Stability & Availability · Heavy lift

⚠️ Unverified finding
Verification ran but could not confirm this finding. It is shown for review, not as a verified issue.

Keep live rollbacks from blocking table access.

If this migration is rolled back while the application serves traffic, each standard DROP INDEX takes an ACCESS EXCLUSIVE lock on its table. A drop that waits behind another transaction can block subsequent reads and writes. Use separate DROP INDEX CONCURRENTLY migrations if live rollback is required, or require a maintenance window for this rollback. (postgresql.org)

Source: Linters/SAST tools

---

Review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 1b0d3810-5fc1-499e-9608-de1a61694470

Commits

Reviewing files that changed from the base of the PR and between df31029 and accba9d.

Files selected for processing: 2

• apps/api/migrations/000016_module_join_indexes.down.sql
• apps/api/migrations/000016_module_join_indexes.up.sql

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 0 remain after this review.