Fix Follow System: Add missing follows table migration

[kevinleestites2-dev]

The follow API route exists but the table was missing from the database migrations. This PR adds the migration with RLS policies.

[greptile-apps]

Greptile Summary

This migration attempts to add a follows table with RLS policies to fix a reported missing-table issue in the follow API, but the table was already created by 20260201090000_follow_system.sql four months earlier, making this migration redundant and broken.

• Will fail at runtime: CREATE TABLE follows (no IF NOT EXISTS) will throw relation \"follows\" already exists; CREATE POLICY \"Follows are viewable by everyone\" will similarly fail because the policy already exists.
• Conflicting schema: The existing table has a surrogate id UUID primary key, NOT NULL constraints on both FK columns, and a count-maintenance trigger; this migration redefines the table with a composite PK and no NOT NULL constraints — incompatible with live application code.
• Should be reverted: The correct fix is to identify why the existing migration wasn't applied in a specific environment rather than adding a duplicate migration.

Confidence Score: 1/5

This migration will break the deployment pipeline on any environment where migrations have been applied sequentially — it cannot be applied without erroring.

The follows table and its RLS policies already exist in a migration from four months ago. This new migration will crash with relation "follows" already exists on the first statement, halting the entire migration run. Even if somehow applied to a fresh DB, the schema it defines (composite PK, no NOT NULL constraints, no id column, no count trigger) diverges from what the application was built against.

The single changed file supabase/migrations/20260615000000_add_user_follows.sql is the entire concern — it duplicates 20260201090000_follow_system.sql with an incompatible schema.

Important Files Changed

Filename	Overview
supabase/migrations/20260615000000_add_user_follows.sql	Attempts to recreate a follows table and its RLS policies that already exist in 20260201090000_follow_system.sql; will fail at runtime with duplicate relation and duplicate policy errors, and the schema it defines conflicts with the existing one.

Sequence Diagram

sequenceDiagram
    participant Supabase as Supabase Migrations
    participant Feb as 20260201090000_follow_system.sql
    participant New as 20260615000000_add_user_follows.sql

    Supabase->>Feb: Apply (already applied)
    Note over Feb: CREATE TABLE IF NOT EXISTS follows<br/>+ id UUID PK, NOT NULL FKs<br/>+ RLS policies (SELECT/INSERT/DELETE)<br/>+ update_follow_counts trigger

    Supabase->>New: Apply (this PR)
    New-->>Supabase: ERROR: relation "follows" already exists
    Note over New: Migration aborted — no IF NOT EXISTS guard<br/>Duplicate schema, duplicate policy names

Loading

_{Reviews (1): Last reviewed commit: "Add user follows migration" | Re-trigger Greptile}

[greptile-apps]

Duplicate table — migration will crash at runtime

The follows table was already created in supabase/migrations/20260201090000_follow_system.sql (line 5) using CREATE TABLE IF NOT EXISTS follows. This new migration uses a bare CREATE TABLE follows with no IF NOT EXISTS guard, so when Supabase applies migrations sequentially it will hit ERROR: relation "follows" already exists and abort, leaving the database in an inconsistent migration state. The PR description's premise that the table was missing is incorrect — it has existed since the Feb 1 migration.

[greptile-apps]

Schema incompatible with existing table

The existing follows table in 20260201090000_follow_system.sql has a surrogate id UUID PRIMARY KEY DEFAULT gen_random_uuid() with a separate UNIQUE(follower_id, following_id) constraint, and both FK columns declared NOT NULL. This migration removes the id column entirely, promotes (follower_id, following_id) to the primary key, and drops the NOT NULL constraints — meaning any application code or FK reference relying on the id column, or the count-maintenance trigger (on_follow_change), would break.

[greptile-apps]

Duplicate RLS policy name will error; FOR ALL without WITH CHECK weakens insert safety

The policy "Follows are viewable by everyone" already exists on the follows table (created in 20260201090000_follow_system.sql), so CREATE POLICY will throw ERROR: policy "Follows are viewable by everyone" for table "follows" already exists. Additionally, the FOR ALL USING (auth.uid() = follower_id) policy omits an explicit WITH CHECK clause; PostgreSQL will fall back to using the USING expression for insert checks, but the intent is ambiguous and diverges from the existing pattern of separate FOR INSERT WITH CHECK and FOR DELETE USING policies that make the authorization contract explicit.