Skip to content

Conversation

@iFurySt
Copy link

@iFurySt iFurySt commented Sep 22, 2025

Fix seed imports to be idempotent by handling duplicate version_id conflicts

Motivation and Context

During seed data imports, duplicate version_id entries could cause database constraint violations and prevent the seed process from completing successfully. This fix makes the seed import
process idempotent by gracefully handling duplicate version_id conflicts using PostgreSQL's ON CONFLICT DO NOTHING clause.

How Has This Been Tested?

  • Tested seed import process with existing data in the database
  • Verified that duplicate version_id entries are silently ignored without errors
  • Confirmed that the seed process can be run multiple times without failures

Breaking Changes

No breaking changes. This is a backwards-compatible bug fix that improves the robustness of the seed import process.

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

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

The fix modifies the CreateServer method in internal/database/postgres.go to use ON CONFLICT (version_id) DO NOTHING when inserting servers. This PostgreSQL-specific syntax ensures that if
a server with the same version_id already exists, the insert operation is silently ignored rather than throwing a constraint violation error.

Copy link
Member

@domdomegg domdomegg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given this is also the main code path for publishing servers, I worry about adding logic to ignore weird states.

Could you explain the use case you have for silently ignoring import errors? E.g. why are you trying to import the same seed multiple times? Then we can think through alternative fixes better if we understand the problem.

@iFurySt
Copy link
Author

iFurySt commented Sep 22, 2025

Xnip2025-09-22_22-39-15

The issue is that every time we run make dev-local, the app runs the seed import again, which tries to insert the same servers and causes duplicate key errors.

You’re right, it was my carelessness, I ended up pushing a bandaid solution. I think the proper fix should be to detect whether the server already exists by version id from the seed file in importerService.ImportFromPath rather than at the INSERT.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants