Feature/submission module#4
Conversation
📝 WalkthroughWalkthroughThe changes add a new database migration to create a submissions table with associated enum types for tracking submission verdicts and status. Additionally, the docker-compose configuration updates the PostgreSQL port binding, and a minor formatting adjustment is made to the Go main function signature. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@migrations/20260309034612_create-submission_table.up.sql`:
- Around line 26-27: Add a CHECK constraint on the submissions table to enforce
the state machine between the status and verdict columns (submission_status and
verdict): require verdict IS NOT NULL when status = 'completed' and require
verdict IS NULL for all non-completed statuses; add a descriptive constraint
name (e.g., submissions_status_verdict_check) in the migration so the database
rejects impossible combinations like status = 'completed' with NULL verdict or
status != 'completed' with a terminal verdict.
- Line 21: The submissions migration defines user_id as a plain BIGINT which
lacks referential integrity; either create the users table in an earlier
migration or change the submissions table definition so user_id enforces a
foreign key (e.g., user_id BIGINT NOT NULL REFERENCES users(id)) and match any
nullability you want; update the CREATE TABLE for submissions (the user_id
column) or add a separate ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY
(user_id) REFERENCES users(id) once users exists so submissions.user_id
references users(id) like problem_id references problems(id).
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5c11cb7d-6315-4bab-a905-8bc57a1eedb6
📒 Files selected for processing (4)
cmd/server/main.godocker-compose.ymlmigrations/20260309034612_create-submission_table.down.sqlmigrations/20260309034612_create-submission_table.up.sql
|
|
||
| problem_id BIGINT NOT NULL REFERENCES problems(id), | ||
|
|
||
| user_id BIGINT, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check whether the schema already defines a users table and how `user_id` is modeled elsewhere.
rg -n -C3 'CREATE TABLE users|REFERENCES users\s*\(' migrations
rg -n -C3 '\buser_id\b' migrations internalRepository: Aneeshie/CPPJudge
Length of output: 611
🏁 Script executed:
# Search entire repository for users table creation and definition
find . -type f -name "*.sql" | head -20
rg -i 'create table.*users' .
rg -i 'create table' migrations | sortRepository: Aneeshie/CPPJudge
Length of output: 459
🏁 Script executed:
# Also check the full migration file to understand context
cat -n migrations/20260309034612_create-submission_table.up.sqlRepository: Aneeshie/CPPJudge
Length of output: 901
🏁 Script executed:
# Search entire repo for any reference to users table
rg -i 'users' . --type sql
git ls-files | grep -E '\.(sql|md|txt)$'Repository: Aneeshie/CPPJudge
Length of output: 298
🏁 Script executed:
cat README.mdRepository: Aneeshie/CPPJudge
Length of output: 1346
Add foreign key constraint to user_id or create users table first.
The user_id field is defined as a bare BIGINT without a foreign key constraint, unlike problem_id which references problems(id). Since a users table does not yet exist in migrations, submissions can reference non-existent user IDs, allowing orphan records and breaking referential integrity. Either create a users table migration first, or add NOT NULL REFERENCES users(id) to user_id when the users table is added.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@migrations/20260309034612_create-submission_table.up.sql` at line 21, The
submissions migration defines user_id as a plain BIGINT which lacks referential
integrity; either create the users table in an earlier migration or change the
submissions table definition so user_id enforces a foreign key (e.g., user_id
BIGINT NOT NULL REFERENCES users(id)) and match any nullability you want; update
the CREATE TABLE for submissions (the user_id column) or add a separate ALTER
TABLE ... ADD CONSTRAINT ... FOREIGN KEY (user_id) REFERENCES users(id) once
users exists so submissions.user_id references users(id) like problem_id
references problems(id).
| status submission_status NOT NULL DEFAULT 'pending', | ||
| verdict verdict, |
There was a problem hiding this comment.
Enforce the status/verdict state machine in the schema.
Right now this table accepts impossible combinations like status = 'completed' with verdict IS NULL, or status = 'pending' with a terminal verdict. That will leak inconsistent rows into every reader of submissions.
Suggested constraint
CREATE TABLE submissions (
id BIGSERIAL PRIMARY KEY,
problem_id BIGINT NOT NULL REFERENCES problems(id),
user_id BIGINT,
code TEXT NOT NULL,
language TEXT NOT NULL,
status submission_status NOT NULL DEFAULT 'pending',
verdict verdict,
+ CONSTRAINT submissions_status_verdict_check CHECK (
+ (status IN ('pending', 'running') AND verdict IS NULL) OR
+ (status = 'completed' AND verdict IS NOT NULL)
+ ),
created_at TIMESTAMP DEFAULT NOW()
);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@migrations/20260309034612_create-submission_table.up.sql` around lines 26 -
27, Add a CHECK constraint on the submissions table to enforce the state machine
between the status and verdict columns (submission_status and verdict): require
verdict IS NOT NULL when status = 'completed' and require verdict IS NULL for
all non-completed statuses; add a descriptive constraint name (e.g.,
submissions_status_verdict_check) in the migration so the database rejects
impossible combinations like status = 'completed' with NULL verdict or status !=
'completed' with a terminal verdict.
1 participant
Summary by CodeRabbit
New Features
Chores
Style