Fix Postgres SERIAL after seeding default clusters (#4752)

[tmestery]

Description

Remove hardcoded BaseModel{ID: 1} from seed() when creating the default SchedulerCluster and SeedPeerCluster in manager/database/database.go. Let the database assign primary keys so inserts use the Postgres sequence (nextval). On an empty database the first rows still receive id = 1; subsequent API-created rows no longer collide with id = 1.

Related Issue

Fixes #4752 — Default seeded scheduler cluster uses ID 1 without incrementing the SERIAL on Postgres.

Motivation and Context

On PostgreSQL, explicitly inserting id = 1 does not advance the SERIAL/BIGSERIAL sequence. The sequence can remain at 1, so the next insert that relies on the default still tries id = 1 and hits 23505 unique violation on the primary key. MySQL/MariaDB/PolarDB (MySQL-compatible) advance AUTO_INCREMENT on explicit inserts, so the bug is Postgres-specific. Omitting the primary key in seed aligns behavior and removes the spurious first-request failure.

Screenshots (if appropriate)

N/A.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation Update (if none of the other choices apply)

Checklist

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 28.10%. Comparing base (0822e3a) to head (db3d3d5).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4753   +/-   ##
=======================================
  Coverage   28.09%   28.10%           
=======================================
  Files         232      232           
  Lines       23131    23125    -6     
=======================================
  Hits         6499     6499           
+ Misses      16192    16186    -6     
  Partials      440      440           

Flag	Coverage Δ
unittests	28.10% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
manager/database/database.go	0.00% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gaius-qi]

@tmestery The reason we explicitly insert id = 1 here is to simplify downstream deployment. The Helm charts default the scheduler cluster ID to 1, and several other components rely on this assumption when they are deployed. If we let Postgres assign the primary key via the sequence, the seeded scheduler cluster may not always end up with id = 1, which would break those deployment dependencies.

If we want to change this behavior, we'll need to carefully evaluate the impact on the Helm charts and the other components that depend on the scheduler cluster ID being 1.

[tmestery]

Thanks for the context @gaius-qi - that makes sense. I wasn't aware the Helm charts depended on id = 1 being stable.

Would it work to keep the explicit insert but just advance the Postgres sequence after so future rows don't collide? Something like:

if db.Dialector.Name() == "postgres" {
    db.Exec("SELECT setval(pg_get_serial_sequence('scheduler_clusters', 'id'), 1)")
    db.Exec("SELECT setval(pg_get_serial_sequence('seed_peer_clusters', 'id'), 1)")
}

That way id = 1 stays intact for deployments but the sequence is in the right place for any new inserts. Happy to update the PR if that works.